Darf man "File of <Record>" noch benutzen?

[Der schöne Günther]

Nicht, dass es verboten wäre.

Ich habe ein paar alte Benutzerdaten die mit einem älteren Delphi-Programm geschrieben wurden und möchte die einlesen. In die Datei wurden ohne Kopf direkt viele, viele Records gleichen Typs geschrieben.

Ich lese es momentan so ein:

Delphi-Quellcode:

[...]
var
   inputFile: File of someRecord;
   returnedData: someRecord;

   [...]
begin
   [...]
   
   try
      AssignFile(inputFile, absoluteFileName);
      [...]
      try
         Reset(inputFile);
         while not Eof(inputFile) do begin
            Read(inputFile, returnedData);
            [...]
         end;
      except
         // Ich habe keine Ahnung, was AssignFile, Reset und Read für konkrete
         // Exceptions werfen könnten...
         on Exception do [...]
      end;
   finally
      CloseFile(inputFile);
   end;
   
   [...]
end;

Alles richtig soweit? Kann man das in 64-Bit-Zeiten, NTFS mit Rechteverwaltung noch machen? Ich habe von Dateizugriffen von der Platte mit Delphi nicht viel Ahnung, einen provisorischen Logger habe ich mit einer TStreamWriter/TFileStream-Kombo gelöst, aber direkt den Record so auslesen zu können war auch sehr komfortabel...

[Union]

Es funktioniert ja und ist einfach. Du könntest das natürlich durch TWriter / TReader ersetzen. Unangenehm sind nur die globalen Variablen die das steuern und damit nicht threadsafe sind.

[Aro]

Hallo,

ich arbeite sehr gerne mit Records, weil mann da wirklich alles zu einem Datensatz bündeln kann was man benötigt. Dazu gehört natürlich auch das einfache Abspeichern in einer Datei und das schnelle und unkomplizierte Abrufen eines bestimmten Records. Ich habe das gelöst, in dem ich mir selbst ein Objekt

TFile = class(TObject) geschrieben habe, das alles macht, was man im Umgang mit Dateien braucht. Die Funktionen kapseln sinnvoll die Windows-Api´s

Davon leite ich ein neues Objekt für Records ab

TRecFile = class(TFile)
private
FRL : Integer; {Recordlänge}
public
constructor CreateFil(FileName: PAnsiChar; Mode, Art, size : Word);
function RecRead(var Buffer): DWORD;
function RecWrite(const Buffer): DWORD;
function RecSeekRead(var Buf; Pos : Integer ): DWORD;
function RecSeekWrite(var Buf; Pos : Integer ): DWORD;

...

Damit kann ich wirklich alles machen. Es geht sehr schnell, da die Api´s direkt aufgerufen werden und es werden nicht mehr Resourcen verbraucht als unbedingt notwendig.

Das ist zwar nicht unbedingt im offiziellen Stiel - da kann man gar nicht genug Objekte erzeugen und wieder freigeben und Speicherplatz binden, aber es ist schnell und sicher.

MfG

Aro

[Mathematiker]

Hallo,
in einem Netzwerk bzw. ohne Schreibrechte kannst Du Probleme bekommen, da reset ein file of record auch zum Schreiben öffnet. Das habe ich selbst schon schmerzlich erlebt.

Deshalb empfehle ich die Verwendung von filemode:

Delphi-Quellcode:

 assignfile(Datei,Name);
 filemode:=0;
 reset(Datei);
...
 closefile(Datei);
 filemode:=2;

Beste Grüße
Mathematiker

[p80286]

Kleine Anmerkung, ich arbeite mit einem buffer der x*sizeof(rec) ist, da läuft dann immer ein Lesezeiger mit. Ist etwas schneller als jeden record einzeln zu lesen.
Schreiben habe ich allerdings (noch) nicht implementiert.

@Der schöne Günther
Was Du suchst ist IORESULT.

Gruß
K-H

[Mavarik]

Natürlich darf man das...

Nutze ich "nur"...

[e-mail]

[jaenicke]

Zitat von Aro:

aber es ist schnell und sicher.

Aber deutlich langsamer als z.B. MMFs zu benutzen. Die vielen kleinen Zugriffe machen das ganze insgesamt sehr langsam, wenn es größere Datenmengen sind.

[sx2008]

Also in der profesionellen Softwareentwicklung darf man eigentlich "File of <Record>" nicht mehr benützen und ich möchte das auch begründen.

1.) der Datei fehlt jeglicher Hinweis auf die enthaltene Datenstruktur
Da aber Daten wichtiger sind als Programme ist dies ein Problem.
Nach "Word 97" kräht heute kein Hahn mehr aber *.doc Dateien die mit dieser Version erzeugt wurden können immer noch wichtig sein.
2.) fehlende Interoparatibilität mit Fremdsoftware.
CVS oder XML-Formate können auch mit anderer Software ausgewertet werden;
ein "file of <Record>" ist ein totes Gleis
3.) fehlende Robustheit gegen Programierfehler und Wechsel der Programmiersprache
Sollte der Programmierer bei der Definition des Record ein Fehler gemacht haben oder soll die Software in andere Progsprachen portiert werden kann es zu Verschiebungen kommen.
Änderungen mit dem Editor sind gefährlich und können die Struktur zerstören.
Im Worstcase kann die ganze Datei zum Datensalat werden.

Oder man Importiert eine Datei mit 40000 Datensätzen in die Datenbank und stellt dann fest, dass alle Felder um ein Zeichen verschoben sind.
Dann ist guter Rat teuer - wie bekommt man die defekten Datensätze wieder aus der Datenbank heraus?
4.) fehlende Erweiterbarkeit
Soll ein Feld vergrössert werden, dann gibt es Schwierigkeiten.
Die Software muss die alte und die neue Struktur beherrschen und ausserdem muss sie wissen ob eine best. Datei die alte oder schon die neue Struktur hat
5.) hoher Dokumentations- und Kommunikationsaufwand
Bei einer CSV-Datei muss man nur die Reihenfolge der Felder und dessen Bedeutung kennen.
Beim "file of <Record>" muss jedes Detail fehlerfrei geklärt sein.
Für jedes Feld Position & Länge, Datentyp und bei Strings die Info ob links- oder rechtsbündig.
Mit CR/LF als Recordtrenner oder ohne Recordtrenner, welcher Zeichensatz?
6.) keine Info welcher Zeichensatz benützt werden soll (CSV und XML können dagegen einen BOM verwenden)

Die Vorteile der einfachen Implementierung und des fehlenden Overheads in der Datei können die Nachteile nicht ausgleichen.

Ich und meine Kollegen haben lange Zeit mit "file of <Record>" Dateien gearbeitet.
Wenn uns heute so eine Datei über den Weg läuft wird geflucht, nach der Doku gesucht (manchmal gibt es keine) und der Taschenrechner wird zum wichtigsten Hilfsmittel.

[Namenloser]

Ich wüsste wirklich nicht, wieso irgendjemand noch die alten Pascal-Routinen verwenden wollen würde, wo es Streams gibt... Ich fand das Arbeiten mit Streams schon immer viel angenehmer und intuitiver. Streams haben außerdem den Vorteil, dass du von jeder Datenquelle einlesen kannst, also nicht nur von der Festplatte, sondern auch aus dem RAM (TMemoryStream) oder ganz woanders her, z.B. von einem Netzwerkstream.

Dein obiges Beispiel mit Streams 1:1 übersetzt:

Delphi-Quellcode:

[...]
var
   Stream: TStream;
   returnedData: TSomeRecord;

   [...]
begin
   [...]
   
   try
      Stream := TFileStream.Create(absoluteFileName);
      [...]
      try
         // Hier unnötig:
         //   Stream.Position := 0;
         while Stream.Read(returnedData, SizeOf(returnedData)) > 0 do begin
            [...]
         end;
      except
         // Exceptions gibt es bei Streams natürlich! Z.B.:
         on EReadError do [...]
      end;
   finally
      Stream.Free;
   end;
   
   [...]
end;

Ist sogar eine Zeile kürzer.

Sehr praktisch finde ich bei Streams, dass man das Schreiben der Datei über mehrere Klassen und Methoden verteilen kann. Man übergibt einfach den Stream als Parameter. So kann man z.B. sehr einfach baumartige Objekt-Strukturen abspeichern... und das Wiedereinlesen geht ganz genau so.

Wenn man es einigermaßen schlau anstellt, kann man solche Binärdateien (im Gegensatz zu File of record, wo man an das "record-Raster" gebunden ist) auch erweiterbar gestalten, indem man z.B. vor jeden Datensatz eine Typen-ID und eine Länge schreibt.

Bei diesem Tutorial kann man sich einige Anregungen holen.

[Der schöne Günther]

Vielen Dank für die neuen Antworten!

Meine ursprüngliche Frage ging weniger um die Struktur, ob man neue Daten so speichern sollte - Ich wollte wissen, ob ich Legacy-Daten, die eben so als Flat File auf die Platte geschrieben wurden auch so wieder einlesen kann. Oder ob es etwas besseres gibt.
Das hat NamenLozer ja jetzt bestens geklärt

Auch wenn ich heute menschenlesbare standarisierte Formate wie CSV oder XML einsetze wo es geht: Bei wirklich massenhaftem Datenaustausch der einigermaßen schnell über die Bühne gehen muss bin ich mir da nicht sicher.
Mein Haus liefert bsp. neuerdings auch Systeme aus, die nur noch noch lokal eine SSD haben und Netzanbindung an eine externe DB ist nicht unbedingt gegeben. Über Jahre hinweg fallen da eine Menge Daten an die vorgehalten werden müssen. Da nehme ich es ehrlich gesagt auch gerne dankend an, wenn ich eine Zehnerpotenz Speicher sparen kann...