XppFatal

[Jan]

Was möchte mir diese Meldung sagen?

FATAL ERROR LOG
Not recoverable Error!
SYS Thread-ID: 464
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (396):
MAIN(248)
Call Stack of GUI Thread (548):
Call Stack of Thread 3 (920):
Call Stack of Thread 4 (1040):
GEDCOMEINLESEN2(401)
(B)GEDCOMEinlesen1(98)
@XBPPUSHBUTTON@I@HANDLEEVENT(968)
GEDCOMEINLESEN1(157)
File: E:\Programme\Familienbuch\FamilienBuch.exe
TimeStamp: 20101227 19:11
End of FATAL ERROR LOG.

Die tritt auf bei einem DbAppend(), durch das in einer Do-While-SchlEife vorher schon mehrere tausend mal fehlerfrei durchgelaufen wurde. Der Fehler ist immer am gleichen Datensatz reproduzierbar.

Jan

[Martin Altmann]

Moin,
könnte es sein, dass in diesem einzulesenden Datensatz ein unerlaubtes Zeichen enthalten ist? Beispielsweise ein ; innerhalb eines Feldes, wodurch dieser Satz ein Feld mehr hat und u.U. ein Feld mit einem anderen Datentyp als eigentlich richtig vorliegt.

Viele Grüße,
Martin

[Jan]

Martin,

der knallt in der Zeile wo nichts anderes als ein DbAppend() gemacht wird ...

Jan

[Martin Altmann]

Jan,
Du wirst doch ein Aufbau des Textfiles definiert haben - oder nicht?
Oder appendest Du von einer DBF in eine andere?

Viele Grüße,
Martin

[AUGE_OHR]

FATAL ERROR LOG
Not recoverable Error!
SYS Thread-ID: 464
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0

wenn du < v1.9 hättest würde ich sagen DEP ein/abschalten ...

Die tritt auf bei einem DbAppend(), durch das in einer Do-While-SchlEife vorher schon mehrere tausend mal fehlerfrei durchgelaufen wurde. Der Fehler ist immer am gleichen Datensatz reproduzierbar.

da ich denke das du den Fehler nicht bei einem "normalen" DbAppend() in einer "normalen" Do/While bekommst.
ich "denke" das es dein CG ist der "überläuft" ...

Frage : benutzt du das ganze für eine Listbox oder Combobox ?

Es könnte auch ein "verspäteter" Fehler sein ...
füge mal diese beiden Zeilen, gleich am Anfang der Main, ein

Code: Alles auswählen

  Error():SetErrorMode( ERR_MODE_GUI, ERR_ACTION_FATAL  )                       
  Error():SetErrorMode( ERR_MODE_GC, ERR_ACTION_FATAL  )

siehe auch PDR 5455 / 5457

auch ja :

Code: Alles auswählen

Set( _SET_OPTIMIZE, .f. )

könnte auch helfen

[Jan]

Hallo Jimmy,

nachdem ich alle drei Zeilen eingefügt habe lautet die Meldung nun so:

FATAL ERROR LOG
in function: atmStartGCThread(void*)
SYS Thread-ID: 464
Module: ATM
Error Codes: EH: 5 Sub: -1073741819(c0000005) OS: 0 XPP: 41
Call Stack of Thread 1 (396):
MAIN(252)
Call Stack of GUI Thread (548):
Call Stack of Thread 3 (920):
Call Stack of Thread 4 (1036):
GEDCOMEINLESEN2(401)
(B)GEDCOMEinlesen1(98)
@XBPPUSHBUTTON@I@HANDLEEVENT(968)
GEDCOMEINLESEN1(157)
File: E:\Programme\Familienbuch\FamilienBuch.exe
TimeStamp: 20101228 05:09
End of FATAL ERROR LOG.

Und zum Überlaufen des GC: Am Ende der Do-Whole-Schleife steht ein Sleep(0). Und das stand da schon immer drin. Also sollte da eigentlich die Möglichkeit zum Aufräumen gegeben sein.

Jan

[Jan]

Jetzt wird es interessant. Gerade habe ich mal versucht, den vorigen Datensatz, also den letzten, der noch appended wird, aus dem Import rauszunehmen. Und siehe da, jetzt läuft das sauber durch.

Aber es stellt sich die Frage: Warum bringt das Einlesen eines Datensatzes das Programm beim nächsten DbAppend() zum Absturz?

Jan

[AUGE_OHR]

Jetzt wird es interessant. Gerade habe ich mal versucht, den vorigen Datensatz, also den letzten, der noch appended wird, aus dem Import rauszunehmen. Und siehe da, jetzt läuft das sauber durch.

war ja schon die Vermutung von Martin das was mit dem Record nicht stimmt ...

Aber es stellt sich die Frage: Warum bringt das Einlesen eines Datensatzes das Programm beim nächsten DbAppend() zum Absturz?

zunächst müsste man ja raus bekommen "was" an dem Datensatz "kaputt" ist.

man könnte aber auch mit BEGIN/SEQUENCE und SKIP das ganze abfangen und "später" eine Meldung ausgeben ...

[Rolf Ramacher]

Hi Jan,

der letzte Datensatz, der appended wurde , ist sauber angelegt mit den richtigen Daten ?

[Jan]

Jimmy,

wo soll ich skippen?

Rolf,

ja, sieht sauber aus. Und wenn ich später die Datenbank mit Andreas' Tool öffne, kann ich sofort einen neuen Datensatz anhängen. Merkwürdig das Ganze...

Jan

[ramses]

Hallo Jan

arbeitest du mit DBF's die MEMO Files haben?

Hast du mal versucht den "Killer Datensatz" mit einem HEX-Editor nach unpassenden Zeichen zu untersuchen oder mit z.B. DBU zu löschen und die Datei zu packen.

Gruss Carlo

[Jan]

Hallo Carlo,

ja, es gibt 2 Memofelder in der Datenbank. Ich habe mal alle Zugriffe darauf aus der Routine rausgenommen, hat aber leider nichts geändert.

Jan

[ramses]

Hallo Jan

könnte es sein dass die DBT Dateien zerschossen sind? Ich hatte auch schon so undefinierbare Probleme bei DBAppend() oder replace xxx with ...., Ursache waren dann zerschossene DBT's. Abhilfe war z.T. durch Kopieren der Datenbank mit DBU in eine neue, rename etc. möglich, oder mit einem Tool MemoPack.EXE aus der alten Zeit auch schon musste ich DBTWEG.EXE verwenden um die Memofelder aus der Datenbank zu entfernen damit wenigstens noch die Datenbank verwendet werden konnte.

Ich verwende seit einem Jahr eine Memofelder mehr, seit dem habe ich nie mehr solche Probleme gehabt.

Gruss Carlo

[Jan]

Hallo Carlo,

nein, zerschossen ist die nicht. Die wird ja für das Einlesen neu erstellt, und die steigt auch immer an exakt dem gleichen Datensatz aus. Wenn ich genau diesen übergehe, gibt es keinerlei Probleme mehr. Es liegt also sicher an den Daten, die ich in diesem Satz schreibe.

Jan

[Koverhage]

Jan,

ich vermute das irgendeine Feldlänge überschritten wird.

[georg]

Hallo,


so aus reiner Neugierde: hast Du mal versucht, die Datei zu schliessen und wieder zu öffnen, bevor Du diesen Datensatz schreibst?


Gruss,

Georg

[Jan]

Halo Georg,

nein, ich habe nur mal nach jedem Satzdurchlauf ein DbCommitAll() eingebaut. Hat extrem verlangsamt, und sonst nix geändert.

Inzwischen konnte ist das Problem in einer langen Nachtschicht lösen. Fragt mich nicht wie, ich weiß es nicht wirklich. An einer Stelle wurde ein Wert falsch interpretiert, aber das passierte vorher schon in dutzenden Datensätzen, ohne das es knallte, da wurde nur eine leere Zeichenkette statt des korrekten Wertes geschrieben. Also nichts wirklich gefährliches. Es irritiert mich aber trotzdem, warum es da einen XppFatal gab, und nicht eine normale, aussagefähige Fehlermeldung.

Jan

[Tom]

Zwei Memofelder? Arbeitest Du mit der ADS?

[Jan]

Moin Tom,

nö, FOXCDX. Mit ein paar angepassten Einstellungen.

Jan

[Tom]

Mmh. Ich benutze nur DBFNTX und ADSDBE, habe aber festgestellt, dass beim Wechsel vom einen auf das andere (seltsame) Fehler auftreten können, wenn mehrere Memofelder vorhanden sind (also mehr als eines). Die Lösung bestand jeweils darin, die Tabellen mit der Engine, mit der sie entstanden sind (DBFNTX), zu öffnen, und via neue Engine (in diesem Fall ADS) umzukopieren. Daher meine Frage. Vielleicht gilt das ja auch für FOX. Falls die Tabellen ursprünglich mit DBFNTX erzeugt wurden.

[Jan]

Ähm, mich beschleicht wieder einmal der Gedanke, als ob ich hier etwas nicht eindeutig dargestellt habe. Mehrfach ist hier von Hilfsbereiten das Importproblem in einer Art angesprochen worden, die einen falschen Hintergrund vermuten lassen.

Der Import geschieht, indem ich eine Textdatei in ein Array einlese (jede Zeile ein Element), und dann das Array Element für Element durcharbeite, auswerte, und die passenden Daten entsprechend aufbereitet in die neu erstellte dbf wegschreibe. Es geht hier NICHT um die Übernahme von Daten aus einer anderen dbf!

Jan

[brandelh]

Gerade habe ich mal versucht, den vorigen Datensatz, also den letzten, der noch appended wird, aus dem Import rauszunehmen. Und siehe da, jetzt läuft das sauber durch.
Aber es stellt sich die Frage: Warum bringt das Einlesen eines Datensatzes das Programm beim nächsten DbAppend() zum Absturz?

Diese Frage kann ich dir beantworten, falls die Vermutung zutrifft, dass du KEIN DBUNLOCK() nach dem letzten Replace benutzt !

DBAPPEND() führt intern ein DBRLOCK() auf den Phantom Satz durch. Hierbei stellt Xbase++ sicher bzw. sollte es sicherstellen , dass die neuesten Daten von der Platte geladen werden.
REPLACE ... schreibt NUR in die Puffer der DBE eventuell auch in die des OS !
ERST bei Satzbewegungen oder DBUNLOCK() wird tatsächlich auf die Platte geschrieben !

Dein "Vorgängersatz" verursacht also ein Problem für die Stelle in der der FATAL auftritt,
aber erst mit dem DBAPPEND() des nächsten Datensatzes wird dieses DBUNLOCK() intern ausgeführt (es sei denn du setzt den Parameter).
Eventuell auch beim internen DBRLOCK() - wer weiß das schon so genau

PS: meist liegen die Fehlerursachen VOR den Fehlerzeilen !

[AUGE_OHR]

An einer Stelle wurde ein Wert falsch interpretiert, aber das passierte vorher schon in dutzenden Datensätzen, ohne das es knallte, da wurde nur eine leere Zeichenkette statt des korrekten Wertes geschrieben. Also nichts wirklich gefährliches.

du könntest beim interpretieren ja auch noch auf VALTYPE() prüfen ob es der gewünschte Type ist ...

[Rolf Ramacher]

Hi Jimmy,

aber dann müßte die fehlermeldung kommen - hat falschen Typ