Fehler "Zu wenig Arbeitsspeicher" beim Füllen der Datenbank

[Thomas2017]

Hallo,
ich habe mich an einem kleinen Datenbank-Programm versucht und bekomme beim Füllen der Datenbank mit Daten den Fehler "Zu wenig Arbeitsspeicher",
nachdem ca. 180 000 Datensätze geschrieben wurden.

Eckdaten: Delphi 7 prof. (alle verfügbaren und relevanten Updates von Embarcadero installiert)

Bei der Datenbank handelt es sich um eine Firebird-Datenbank (embedded).
Ich nutze die Interbase-Komponenten von Delphi 7.

Hier der Teil, der den Speicherfehler verursacht:
Ich lese aus der Textdatei C:\daten.txt die Daten zeilenweise aus und
übertrage sie folgendermaßen in die Datenbank.

Delphi-Quellcode:

  AssignFile(F, 'C:\daten.txt');
  reset(F);
  repeat
    begin
      readln(F, temp);
      x := x + 1;
      form1.DataSet1.append;
      form1.DataSet1.Edit;
      form1.DataSet1.FieldByName('NAME').AsString := temp;
    end
  until eof(F);

  showmessage('...fertig.  ' + inttostr(x) + ' Datensätze');

Lasse ich das Schreiben in die Datenbank weg, tritt der Fehler nicht auf.

Da es ein 32-Bit-Programm ist, beträgt der maximale (virtuelle) Speicher (da noch nicht erweitert, weil keine Ahnung wie...) 2 GB,
der durch das Programm belegt werden kann.
Zur Laufzeit werden jedoch "nur" ~500 MB RAM-Speicher belegt.
Der Rechner hat satt RAM (32 GB) und es ist auch stets genug freier Speicher vorhanden.

Ich habe testweise alle 1000 Datensätze
DataSet1.ApplyUpdates; abgesetzt, hat aber den Fehler nicht abgestellt.

Ferner habe ich
DataSet1.CachedUpdates :=false; ausprobiert, was nach meinem Kenntnisstand bewirken soll, das die Änderungen sofort in die Datenbank geschrieben werden sollen und nicht im
virtuellen Speicher zwischengespeichert werden sollen.
Das hat auch nichts gebracht.


Weiss jemand, woran es liegt und was zu tun ist?

[mkinzler]

Das Edit ist nicht notwendig, da Append direkt in den Editmodus wechselt. Ich würde einen expliziten Post einfügen.
Wie sehen die Transaktionseinstellungen aus?

[Thomas2017]

Mit dem Post in der Schleife hat es auch nichts geändert.


Ich habe eine Transaction1 in dem Programm, welche beim Programmstart
aktiv geschaltet wird.
Die anderen Eigenschaften der Transaction1 habe ich bis auf die Datenbank nicht verändert.

Welche Eigenschaften interessieren dich?

[Uwe Raabe]

Zitat von Thomas2017:

Ich habe eine Transaction1 in dem Programm, welche beim Programmstart
aktiv geschaltet wird.

Das bedeutet aber, daß die Transaktion über den gesamten Einfügevorgang aktiv ist, oder? Für den Embedded-Driver, der ja im Kontext deines Prozesses läuft, kann das aber schon mal den Speichertod bedeuten.

Versuch doch mal, die Transaktion vor dem Einfügen zu beenden. Geht es dann?

[jobo]

Zitat von Thomas2017:

Ich habe testweise alle 1000 Datensätze
DataSet1.ApplyUpdates; abgesetzt, hat aber den Fehler nicht abgestellt.

Vielleicht lieber die Transaction commiten und eine neue starten?

[Thomas2017]

Ich habe die Tranaction vor dem Einfügen deaktiviert.
Der Fehler bleibt davon aber unberührt.

Wenn die Transaktion nicht active ist, macht es da denn dann in Bezug auf den Fehler überhaupt Sinn,
diese zu committen und dann wieder neu zu starten?


Ich hatte auch getestet, alle 1000 Datensätze das Dataset zu deactivieren und dann wieder vor dem nächsten Datensatz zu activieren,
aber das brachte auch keinen Erfolg.

Kann denn der virtuelle Speicher, der durch das Dataset belegt ist, wieder freigegeben werden ähnlich dem free einer stringlist?

[mkinzler]

In FireBird geht nichts ohne Transaktionen. Selbt reine Lesezugriffe benötigen einen Transaktionskontext.
Führ mal regelmässig einen Commit durch. (Z.B. je 1000 Datensätze).

[hoika]

Hallo,
ich würde auf Query umstellen.
Wer weiss, wass diese TTable-Dingens im Hintergrund alles anstellt,
um auf einen SQL-Server zugreifen zu können, u.a. werden die Daten ja lokal (in der Exe) gecacht.

[jobo]

"auf Query umstellen, wer weiß .." würde ich nicht unbedingt, auch wenn es nicht sicher nicht verkehrt wäre. Aber finde ich trotzdem ein gutes Stichwort:

Falls das Dataset noch an die UI gebunden ist, dann rappelt es natürlich ganz schön.

[mkinzler]

Zitat:

um auf einen SQL-Server zugreifen zu können, u.a. werden die Daten ja lokal (in der Exe) gecacht.

Der SQL-Server läuft zudem im Prozessraum der Anwendung.