AScomp hat folgendes geschrieben :

Die Datenmenge lässt sich nicht reduzieren - wenn der Anwender 2 TB an Daten wegsichern möchte und ein Protokoll dazu braucht, dann ist die Datenmenge nunmal nicht kleiner zu bekommen.

Dann teile doch die Datenmenge auf, z. B. nach jeweils 10.000 Einträgen die StringListe wegschreiben, die StringListe leeren und wieder bis zum 10.000. Eintrag füllen, in neue Datei wegschreiben, leeren usw.

Für Fehlermeldungen könntest Du ja eine extra StringListe verwenden.

Gerd Kayser hat folgendes geschrieben :

AScomp hat folgendes geschrieben : Die Datenmenge lässt sich nicht reduzieren - wenn der Anwender 2 TB an Daten wegsichern möchte und ein Protokoll dazu braucht, dann ist die Datenmenge nunmal nicht kleiner zu bekommen. Dann teile doch die Datenmenge auf, z. B. nach jeweils 10.000 Einträgen die StringListe wegschreiben, die StringListe leeren und wieder bis zum 10.000. Eintrag füllen, wegschreiben, leeren usw. Für Fehlermeldungen könntest Du ja eine extra StringListe verwenden.

Dann kann ich die Daten aber auch direkt in die Datei schreiben (und diese geöffnet lassen). Ist insofern einfacher, weil sonst ein Teil im Speicher ist, der andere in der Datei.

Gut, bei 10 Millionen Einträgen ist das ja auch schon rechnerisch klar... selbst bei nur 100 Zeichen pro Zeile.
10.000.000 Einträge * 100 Zeichen * 2 Byte = 2.000.000.000 Byte

Und ein 32-Bit Programm kann nun einmal nur 2 GiB RAM nutzen, egal was du machst. Bei einer deratigen Datenmenge kannst du niemals alles im Speicher halten.

jaenicke hat folgendes geschrieben :

Gut, bei 10 Millionen Einträgen ist das ja auch schon rechnerisch klar... selbst bei nur 100 Zeichen pro Zeile. 10.000.000 Einträge * 100 Zeichen * 2 Byte = 2.000.000.000 Byte Und ein 32-Bit Programm kann nun einmal nur 2 GiB RAM nutzen, egal was du machst. Bei einer deratigen Datenmenge kannst du niemals alles im Speicher halten.

Ich bin bisher schlicht nicht von so umfangreichen Datenmengen ausgegangen. Aber es kommt jetzt immer häufiger vor, dass ein paar hunderttausend Dateien gesichert werden sollen.

Darum bin ich jetzt auch umgestiegen auf das direkte Wegschreiben in eine Datei. Ist zwar beim Zugriff jetzt etwas schwieriger, da die Daten nicht mehr so leicht zu holen sind wie bisher, aber auf längere Sicht mit Sicherheit von Vorteil.

Danke euch für die Unterstützung!

Ich würde den Logzeilen einen festen Aufbau geben, dann kann man recht einfach und bequem nach Fehlern suchen. Zum Beispiel so:



Wenn die Fehlercodes schön untereinander in die Logdatei geschrieben werden, ist es ein leichtes, z. B. mit Readln diese Zeilen zu ermitteln und anzuzeigen.

Gerd Kayser hat folgendes geschrieben :

Ich würde den Logzeilen einen festen Aufbau geben, dann kann man recht einfach und bequem nach Fehlern suchen. Zum Beispiel so: markieren Quelltext     1: lfd. Nummer - Zeitstempel - Fehlercode - Dateiname Wenn die Fehlercodes schön untereinander in die Logdatei geschrieben werden, ist es ein leichtes, z. B. mit Readln diese Zeilen zu ermitteln und anzuzeigen.

Es geht hier aber nicht um ein Fehlerlog, sondern um ein Protokoll darüber, welche Dateien mit welchem Zeitstempel gesichert wurden.

AScomp hat folgendes geschrieben :

Es geht hier aber nicht um ein Fehlerlog.

Ich rede von einem Backup-Log. Wenn Du meinst, daß während der Sicherung keinerlei Probleme auftreten können (Rechteproblem, eklusiv geöffnete Dateien usw.), dann lasse halt die Fehlercodes weg.

Gerd Kayser hat folgendes geschrieben :

AScomp hat folgendes geschrieben : Es geht hier aber nicht um ein Fehlerlog. Ich rede von einem Backup-Log. Wenn Du meinst, daß während der Sicherung keinerlei Probleme auftreten können (Rechteproblem, eklusiv geöffnete Dateien usw.), dann lasse halt die Fehlercodes weg.

Das Fehler-Log ist vom Backup-Log getrennt. Bisher war das gemeinsam in einer StringList, jetzt habe ich es aber getrennt in verschiedene Dateien (weil am Ende sowieso zwei versch. Dateien für beide Logs erstellt werden).

Mir ist klar, wie ich Daten aus einer Datei lesen kann, darum ging es ja nicht. Der Punkt ist nur, dass das Lesen aus einer großen Datei deutlich länger braucht als das Lesen aus dem Speicher. Aber wie gesagt, das Problem ist zufriedenstellend gelöst.

AScomp hat folgendes geschrieben :

Der Punkt ist nur, dass das Lesen aus einer großen Datei deutlich länger braucht als das Lesen aus dem Speicher.

Da kann man sicherlich einiges optimieren.

Vor ein paar Jahren gab es mal eine Diskussion in einer Newsgroup zum Thema, wie man aus einer Datei größer 100 MB alle Leereichen durch ein anderes Zeichen austauschen kann. Bei den ersten Versuchen dauerte das etwa 20 Minuten. Zum Schluß waren es unter 2 Sekunden, wenn ich die Zahlen noch richtig im Kopf habe.