XppFatal bei DbAppend() [Erledigt]

[Jan]

In einem anderen Forenbereich hatte ich ja von meinen Problemen beim Einlesen in ein größeres Array geschrieben. Ich schreibe das also komlett um auf direktes Datenbankschreiben. Aber sofort habe ich wieder ein Problem: Wenn ich die schon bei den Arrays problematische Datei von ca. 44 MB Größe einlese, dann gibt es in der zeile mit dem DbAppend() einen XppFatal. Der sieht dann so aus:

Code: Alles auswählen

FATAL ERROR LOG 
Not recoverable Error!
SYS Thread-ID: 500 
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (392):
MAIN(199)
Call Stack of GUI Thread (584):
Call Stack of Thread 3 (1028):
Call Stack of Thread 4 (1140):
STANDARDEH(85)
(B)ERRORSYS@0000(52)
GEDCOMEINLESEN2(279)
(B)GEDCOMEinlesen1(90)
@XBPPUSHBUTTON@I@HANDLEEVENT(968)
GEDCOMEINLESEN1(150)
File: E:\Programme\MeinProgramm\MeinProgramm.exe
TimeStamp: 20090923 10:36
End of FATAL ERROR LOG.

Lese ich eine kleinere Datei ein, dann gibt es keinen Fehler. Die Zeile 279 hat nur einen Inhalt, nämlich das DbAppend(). Es würde damit der 75.135te Datensatz angelegt werden. Die gesamte dbf-Größe liegt bei 83 MB, der Index dazu ist 38 MB groß. Datenbank ist FoxCdx.

Jan

[Martin Altmann]

Jan,
zeige mal Deinen Code um das DbAppend() herum...

Viele Grüße,
Martin

[brandelh]

Hallo Jan,

das muss an deiner Methode liegen wie du die Textdatei in kleinere Bestandteile aufteilst, 50 MB sind keine großen Dateien für Xbase++

[Jan]

So, nachdem ich grippegetört stundenlang rumpribiert habe, kristallisiert sich folgendes heraus: Es ist auf jedenfall nicht der DbAppend(), der den XppFatal verursacht. Das behauptet nur die Fehlermeldung so.

Der Punkt ist der, das innerhalb von ca. 2 Min. ca. 2,6 Mio. Importzeilen abgearbeitet werden, die dann ca. 250.000 Datensätze in eine einzelne dbf geschrieben (eigentlich kommen nochmal eine ganze Menge in eine zweite dbf geschrieben, aber soweit bin ich noch nicht). Jeder Datensatz bekommt im Moment 2-7 Felder geschrieben, da habe ich auch noch nicht alle eingebaut. Jedes Feld kann aber nicht einfach mit der Importzeile beschrieben werden, da muß mit SubStr() und manchmal mit Val(SubStr()) erst der korrekte Wert herausgefiltert werden. Und diese Kombination verursacht den Fehler.

Alle Felder mit einem festen Wert beschreiben verursacht keinen Absturz.
Eine kleinere Importdatei einzulesen mit Herausfiltern der korrekten Werte verursacht keinen Absturz.
Nur die große Datei mit Herausfiltern verursacht den Absturz nach ca. 70.000 geschrieben Datensätzen.
Ein Sleep(0) oder ein DbCommit() bringt garnichts.

Warum bringt ein einfaches SubStr() oder Val(SubStr()) den Einlesevorgang bei großen Datenmengen dermaßen aus dem Tritt?

Jan

[brandelh]

das innerhalb von ca. 2 Min. ca. 2,6 Mio. Importzeilen abgearbeitet werden

Respekt, das ist ja richtig schell ...
ich denke dass es am Garbage Collector liegt, wenn er zu schnell zu viel aufräumen muss.
Eventuell solltest du einzelne (größere) Werte schnellstmöglich auf NIL setzen und danach ein skip(0).

[Jan]

Hallo Hubert,

ist das schnell? Keine Ahnung, so viele Daten habe ich voher noch nie eingelesen.

Mit dem Skip(0) werde ich mal versuchen. Im Moment läuft gerade eine extrem langsame Testversion, die nach jeder Importzeile ein DbCommit() macht. Also DAS ist wirklich langsam! (bin gerade bei 290.000 Zeilen, da kommt also noch ein wenig was ) Sobald der durch ist versuche ich das mal mit Deinem Vorschlag. Ein Zurücksetzen auf NIL ist meiner Meinung nach nicht notwendig. Der Inhalt einer einzelnen zu zerhackenden Zeile ist 500 Zeichen lang, wovon nur max. 50 Zeichen benötigt werden.

Jan

[brandelh]

Hi,

ich brauche hier auf einem Athlon 3000+ mit IDE Laufwerk für 19.000.000 Zeilen 19 Minuten

[Jan]

Das Teil treibt mich zur Verzweiflung!!!

Sobald ich keinen Dummywert einlese, stürzt das Programm ab. Je nach vorhandenem Datenbestand (ich lese teilweise in einen vorhandenen Datenbestand ein, teilweise in einen frischen) stürzt das Programm früher oder später ab. Irgendwo zwischen 4.500 und 550.000 eingelesenen Importsätzen. DbCommit() oder DbSkip(0) ändern garnichts.

Inzwischen habe ich sogar mal versucht, den Datenstring nicht in der Replace-Zeile auszulesen sondern vorher in eine Variable einzulesen. Ändert garnichts.

Das kann ja noch lustig werden

Jan

[Jan]

So, nach einigen weiteren grippeschwangeren Dauerversuchen habe ich den Fehler wohl gefunden: Wie oben schon gesagt ist die Fehlermeldung falsch und führt auf die falsche Fährte (soll ich die unnütz vergeudete Arbeitszeit jetzt Alaska in Rechnung stellen? ). Es ist NICHT die DbAppend()-Zeile, die den XppFatal bewirkt.

Ich extrahiere ja den zu speichernden Wert über SubStr() aus der kompletten Importzeile. Und dabei gibt es einen speziellen Typen von Importsatz, in dem ich mich über At() und RAt() an die richtigen Positionen ranarbeiten muß. Und dabei gibt es offensichtlich Sätze, in denen SubStr() eine negative Länge zurückgibt. Was dann den Fehler provoziert.

Was mir total unklar ist: Warum passiert das an unterschiedlichen Positionen der Importdatei passiert. Eigentlich müsste das doch immer an der gleichen Stelle passieren. Und: Warum gibt das einen XppFatal? Das müsste doch einen XbpError geben wegen falscher Rückgabewerte von SubStr().

Naja, wie auch immer: Vielen Dank für alle guten Hinweise und die Mühen, die Ihr Euch gemacht habt.

Jan

[Martin Altmann]

Hallo Jan,
wieso? substr() arbeitet auch mit negativen Werten (schau mal in die Hilfe) - das ist dann nicht von links, sondern von rechts zählend...

Viele Grüße,
Martin

[Jan]

Hallo Martin,

mag sein. Aber da liegt das Problem irgendwo. Denn seitdem ich da eine Sicherung drin habe funtioniert das. Aber das mag genau so ein Problem sein wie mit StrTran(). Ich kann definitiv kein Chr(13) oder Chr(10) damit ersetzen! Herbert war es glaube ich der sagte, daß es bei ihm ginge. Bei mir aber nicht, ich hab das heute vormittag extra noch einmal ausprobiert.

Vielleicht sollte ich mal mein Xbase++ neu installieren?

Jan