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] :stupid:

[jaenicke]

Zitat:

Zitat von Aro (Beitrag 1223167)

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 :thumb:

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...

[sx2008]

Zitat:

Zitat von Der schöne Günther (Beitrag 1223197)

Da nehme ich es ehrlich gesagt auch gerne dankend an, wenn ich eine Zehnerpotenz Speicher sparen kann...

Da hat CSV durchaus Vorteile weil anhängende Leerzeichen nicht mitgespeichert werden.
Wie gesagt man muss Vor- und Nachteile gegen einander abwägen.
Ein Format mit festen Records hat da einfach zu viele Nachteile.

[Blup]

"File of <Record>" ?
Wenn es wirklich auf große Datenmengen und Geschwindigkeit ankommt, sind "Memory Mapped Files" die bessere Lösung.

[p80286]

@sx2008
Für alle Projekte mit Zukunft kann ich Dir nur zustimmen.

Zitat:

Zitat von sx2008 (Beitrag 1223191)

Nach "Word 97" kräht heute kein Hahn mehr aber *.doc Dateien die mit dieser Version erzeugt wurden können immer noch wichtig sein.

Auch damals gab es schon RTF, aber dafür hätte man Benutzer schulen müssen.

Zitat:

Zitat von sx2008 (Beitrag 1223191)

Änderungen mit dem Editor sind gefährlich und können die Struktur zerstören.
Im Worstcase kann die ganze Datei zum Datensalat werden.

Insbesonders wenn der Editor Blanks zu Tabulatoren macht, und noch ein zweiter in Spiel kommt, der die umgekehrte Übersetzung mit einer anderen Anzahl blanks durchführt.

Allerdings habe ich es schon erlebt, das sowohl XML als auch CSV durch editoren und Excel massakriert wurden.

Zitat:

Zitat von sx2008 (Beitrag 1223191)

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?

So etwas kommt vor, aber das liegt vielleicht auch ein wenig am oberflächlichen Umgang mit den vorhandenen Daten?

Um Deine erste Aussage noch einmal aufzugreifen, wir betreiben hier "Datenverarbeitung" und da sollten wir Daten auch mit größtmöglicher Sorgfalt behandeln.

Gruß
K-H

[sx2008]

Zitat:

Zitat von p80286 (Beitrag 1223207)

Zitat:

Zitat von sx2008 (Beitrag 1223191)

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?

So etwas kommt vor, aber das liegt vielleicht auch ein wenig am oberflächlichen Umgang mit den vorhandenen Daten?

Ich sehe die Schuld mehr beim Datenformat.
Ein Kunde exportiert z.B. regelmässig seinen Kundenstamm in dieses fixed record format und importiert es dann mit einer anderen Software in eine Datenbank.
Durch Änderungen in seiner IT ändert sich der Zeichensatz von ISO 8859-1 auf UTF-8.
Er hat den Import zwar getestet, nur waren halt keine Umlaute in den Testdaten.
Im Echtbetrieb sind aber Umlaute enthalten (UTF-8 Multibytezeichen) und schon verschiebt sich alles.
Oder seine Daten stammen aus einem Unix-System und werden per FTP in die Windowswelt kopiert.
Dabei wird auch der Zeilenumbruch von CR --> CR/LF umgewandelt.
Aber einmal nicht aufgepasst (weil binary statt text-Mode verwendet) und alle Records sind um ein Zeichen zu kurz was "wunderhübsche" Datenverschiebungen zur Folge hat.

In der Importsoftware haben wir dann eine Prüfung eingebaut:

Delphi-Quellcode:

if FileSize mod RecordSize <> 0 then Fehler()

Das gab aber auch wieder Ärger denn abundzu kam es vor, dass hinter dem letzten Record noch ein End-Of-File Zeichen klebte.

[Mavarik]

Zitat:

Zitat von sx2008 (Beitrag 1223191)

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

Oje... Unnötig zu erwähnen, dass ich Dir eigentlich in keinem Punkt zustimmen kann...

Stopp...

Doch Du hast in alles Punkten recht...Nicht weiter lesen...

Wenn man eine Software programmiert, die Dateien bearbeitet, die ein User in irgend einer Form mit anderer Software auch bearbeiten können muss...

Aber [OT]

Ich will nicht, dass:

1. Meine Anwender auch nur die Möglichkeit haben die Dateien zu editieren.
2. Dritte in die Dateien reinschauen können.
3. Kompatibilität zu Vorgänger-Versionen herzustellen ist.
4. --- Punkt gestrichen ---

Daher werden alle Daten-Dateien Verschlüsselt, mir jeweils anderer Reihenfolge pro Programmstart gespeichert,
jeweils mit anderem Offset versehen, die Verschlüsselung ändert sich per Zufall usw. Querbeziehungen stellen eine
Manipulation fest, redundante Speicherung verhindert Datenverlust. Und alles was mir in den letzten 31 Jahren noch so eingefallen ist.

[/OT]

Mavarik

PS: Unnötig zu erwähnen, dass es nix schnelleres gibt als ein Blockread... Wenn die Datensatzlängen dann noch glatte Sektorgrößen/Binärlängen haben...Und der Lesepuffer so viele Daten aufnehmen kann wie die Festplatte in einer Umdrehung
lesen kann....

PPS: Achja, dass waren noch Zeiten, als man den Floppy-Controller und die DMA noch per ASM angesprochen hat.

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1223214)

Ich will nicht, dass:

1. Meine Anwender auch nur die Möglichkeit haben die Dateien zu editieren.
2. Dritte in die Dateien reinschauen können.
3. Kompatibilität zu Vorgänger-Versionen herzustellen ist.
4. --- Punkt gestrichen ---

Daher werden alle Daten-Dateien Verschlüsselt, mir jeweils anderer Reihenfolge pro Programmstart gespeichert,
jeweils mit anderem Offset versehen, die Verschlüsselung ändert sich per Zufall usw. Querbeziehungen stellen eine
Manipulation fest, redundante Speicherung verhindert Datenverlust. Und alles was mir in den letzten 31 Jahren noch so eingefallen ist.

[/OT]

:shock: Ist das dein Ernst? Wo sind die Ironie-Tags?

Zitat:

PS: Unnötig zu erwähnen, dass es nix schnelleres gibt als ein Blockread... Wenn die Datensatzlängen dann noch glatte Sektorgrößen/Binärlängen haben...Und der Lesepuffer so viele Daten aufnehmen kann wie die Festplatte in einer Umdrehung
lesen kann....

Ich weiss nicht, in welchem Jahrhundert Du lebst, aber erstens gibt es schnelleres als ein Blockread (ReadFileGather, MMF usw.), zweitens macht Dir deine Win-API mit ihrer Systempage einen Strich durch die Rechnung und drittens kräht im 21.Jahrhundert kein Hahn mehr primär nach Performance.

Wartbarkeit, Erweiterbarkeit, Robustheit sind die Schlagworte. Wenn das alles gewährleistet ist, kannst Du über Performance nachdenken. Oder wenn Du ein RDBMS schreibst, oder einen Datenlogger, von mir aus.

Die gängigen und modernen Dateiformate und Bibliotheksfunktionen sind eh schnell genug und fast immer wartet die Anwendung auf den Anwender und nicht umgekehrt. Ich mache mir jedenfalls keine Gedanken mehr über Probleme, die vor 30 Jahren schon gelöst wurden.

Zitat:

PPS: Achja, dass waren noch Zeiten, als man den Floppy-Controller und die DMA noch per ASM angesprochen hat.

Gott-Sei-Dank sind die vorbei und man muss nicht mehr in der Buddelkiste Häuschen bauen sondern kann mit ausgereiften Werkzeugen Städte konzipieren und errichten (lassen).

Wenn mir ein altes 'File-Of-Record' über den Weg läuft, welches ich lesen muss, dann drücke ich jedes Mal die Daumen, ob die Feldausrichtung der Recordelemente immer noch genau so ist, wie damals. Das Problem hat man ja -nebenbei bemerkt- nicht nur bei Dateien, sondern leider werden auch viele Daten so verschickt.

Ich gehe mittlerweile so vor, das ich Element für Element einzeln aus dem Stream fische. So kann ich padding Bytes, Endianverknurpselungen oder sonstige exotische Dateitypen individuell abfangen.

Wenn ich Objekte serialisiere (was einem File-Of-Record ähnlich ist), dann bekommen meine Objekte eine Versionsnummer. Die steht in jedem 'Record' als erstes. Anhand dieser Nummer kann ich dann entscheiden, wie ich vorgehe und welche Eigenschaften in welcher Reihenfolge gelesen werden.

XML finde ich persönlich grauslich, aber nur, weil die Datei 'ein wenig' größer wird, als beabsichtigt. Ansonsten ist es idiotensicher und eignet sich auch zum Austausch mit Daten aus der inneren Mongolei. Hier ist JSON für mich geeigneter, weil es genauso idiotensicher ist, aber eben kompakter.

Um die Frage des TE zu beantworten: Man darf, wenn man muss, aber man sollte nicht, wenn man die Wahl hat.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1223224)

XML finde ich persönlich grauslich, aber nur, weil die Datei 'ein wenig' größer wird, als beabsichtigt.

Es gibt ja bereits einige weit verbreitete Formate, angefangen bei den beiden großen Office-Formaten, die die XML-Daten gezippt speichern. Damit hat man die Metainformationen des XML-Formats zusammen mit relativ kleinen Dateien und kann zudem Inhalte wie Bilder auch gleich geordnet mit speichern, falls erforderlich.

[gammatester]

Einige der Hauptgründe für ein file of record sind doch wohl,

• man hat Randomaccess auf einzelne Records ohne Indexdateien (man eine Datei etc),
• man kann einzelne Records ändern und an die gleiche Position zurückschreiben (ohne den Rest der Datei zu ändern, diese zu kopieren erc),
• man kann für einzelne Records Checkdaten (zb CRC) einfach berechnen, ändern und verifizieren,
• ...

Kann mir jemand erklären, wie man diese Anforderungen erreicht, wenn man die Daten als Text serialisiert (womöglich noch Compiler abhängig), sie dann aber vielleicht noch zippen muß, weil die Datenmenge dann doch überraschenderweise etwas zu groß wird.

[Daniel]

Bekanntermaßen führen viele Wege nach Rom. Und die o.g. Anforderungen lassen sich mit typisierten Dateien prinzipiell natürlich erreichen. Auf die möglichen Probleme, die dieser Weg mit sich bringen kann, wurde ja schon völlig richtig hingewiesen. Wenn es wichtig sein sollte - warum auch immer - punktuell nur einzelne Bereiche einer Datei zu beschreiben, dann können typisierte Dateien wieder hoch im Kurs stehen.

Letztlich ist auch "File of Record" nur eines von mehreren Werkzeugen der Softwaretechnik und man wird in Abhängigkeit der Anforderungen seine Wahl treffen müssen.

[Der schöne Günther]

Zitat:

Zitat von Furtbichler (Beitrag 1223224)

Hier ist JSON für mich geeigneter, weil es genauso idiotensicher ist, aber eben kompakter.

Kleine Anekdote am Rande: Es war immer wieder lustig, wenn Delphi in der Serialisierung nach JSON Fließkommazahlen mit Kommas ausgespuckt hat. Was dann mit einem JSON-Stream passiert kann man sich vorstellen :-D. Nicht ganz so idiotensicher wie XML würde ich sagen 8-)

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1223224)

Wartbarkeit, Erweiterbarkeit, Robustheit sind die Schlagworte. Wenn das alles gewährleistet ist, kannst Du über Performance nachdenken.

Das merkt man einigen Programmen an. Die sind so mit dem Suchen einer möglichen Erweiterung beschäftigt, daß für ihren eigentlichen Zweck nichts mehr übrig bleibt.
Grundsätzlich hat ein Programm seine Arbeit so schnell es geht zu erledigen, und dabei immer nach dem alten Motto "First make it run, then make it fast"

Gruß
K-H

[Mavarik]

Zitat:

Zitat von Furtbichler (Beitrag 1223224)

Zitat:

Zitat von Mavarik (Beitrag 1223214)

Ich will nicht, dass:

1. Meine Anwender auch nur die Möglichkeit haben die Dateien zu editieren.
2. Dritte in die Dateien reinschauen können.
3. Kompatibilität zu Vorgänger-Versionen herzustellen ist.
4. --- Punkt gestrichen ---

Daher werden alle Daten-Dateien Verschlüsselt, mir jeweils anderer Reihenfolge pro Programmstart gespeichert,
jeweils mit anderem Offset versehen, die Verschlüsselung ändert sich per Zufall usw. Querbeziehungen stellen eine
Manipulation fest, redundante Speicherung verhindert Datenverlust. Und alles was mir in den letzten 31 Jahren noch so eingefallen ist.

[/OT]

:shock: Ist das dein Ernst? Wo sind die Ironie-Tags?

Natürlich ist das mein Ernst... Außerdem schützt es meine Entwicklung.

Zitat:

Zitat von Furtbichler (Beitrag 1223224)

Zitat:

PPS: Achja, dass waren noch Zeiten, als man den Floppy-Controller und die DMA noch per ASM angesprochen hat.

Gott-Sei-Dank sind die vorbei und man muss nicht mehr in der Buddelkiste Häuschen bauen sondern kann mit ausgereiften Werkzeugen Städte konzipieren und errichten (lassen).

Mag sein, aber 1982 hab ich ein Betriebssystem inkl. Diskeditor für Floppys in Z80 ASM programmiert und das hatte nur 1000 Bytes... Da kannte ich jedes bit mit Vornamen. Heute würde man wahrscheinlich 10MB brauchen und es wäre nicht halb so schnell.



Mavarik

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1223234)

Letztlich ist auch "File of Record" nur eines von mehreren Werkzeugen der Softwaretechnik und man wird in Abhängigkeit der Anforderungen seine Wahl treffen müssen.

Diplomatisch wie immer... :thumb:

Und natürlich hast Du 100%ig Recht!

Mavarik

[Sherlock]

Zitat:

Zitat von Mavarik (Beitrag 1223281)

Natürlich ist das mein Ernst... Außerdem schützt es meine Entwicklung.

Nicht nur Deine Entwicklung schützt du damit. Der Support-Aufwand hält sich in Grenzen wenn Anwender nicht in Daten rumwurschteln können, wie sie wollen.
Wir hatten allerdings sogar schon den Fall, daß ein Kunde auf die glorreiche Idee kam eine EXE im Hex-Editor zu bearbeiten, um irgendeinen String in einem Dialog zu ändern. Die Betriebserlaubnis für das Medizinprodukt ist natürlich erloschen, und eigentlich hat sich der Mensch strafbar gemacht...aber wir haben einfach mal den Servicevertrag gekündigt.

Sherlock

[p80286]

Zitat:

Zitat von Sherlock (Beitrag 1223287)

Wir hatten allerdings sogar schon den Fall, daß ein Kunde auf die glorreiche Idee kam eine EXE im Hex-Editor zu bearbeiten, um irgendeinen String in einem Dialog zu ändern.

da scheint es mehrere von zu geben.

Gruß
K-H

[Furtbichler]

Zitat:

Zitat von p80286 (Beitrag 1223256)

Grundsätzlich hat ein Programm seine Arbeit so schnell es geht zu erledigen

Äh. In der professionellen Softwareentwicklung eher nicht, denn da erntest Du mit dieser Aussage Hohn, Spott und abfälliges Schmunzeln.

Zitat:

Zitat von gammatester (Beitrag 1223233)

Kann mir jemand erklären, wie man diese Anforderungen erreicht

Datenbank, fällt mir auf Anhieb ein. SQLite, Access. Was kleines eben. Ich wähle meine Werkzeuge anhand der Anforderung. Wenn ich wahlfreien Zugriff benötige (mit Sicherheit über einen Schlüssel), nehme ich eine DB.

Zitat:

Zitat von Sherlock (Beitrag 1223287)

Nicht nur Deine Entwicklung schützt du damit. Der Support-Aufwand hält sich in Grenzen wenn Anwender nicht in Daten rumwurschteln können

Ich weiss ja nicht, was für und welche Daten ihr da in so einem File-Of-TIrgendwas verschlüsselt abspeichert, aber bei mir ist das so: Eine Liste kommt in eine DB, Konfigurationseinstellungen in eine XML/INI usw.

Ich hatte bisher erst einen Fall, bei dem die Daten geschützt sein mussten. Dann wird eben verschlüsselt. Aber nur, weil es sich um einen embedded PC handelte, ohne Netzanbindung und keinerlei DB-Treiber installiert werden durften. Ansonsten schütze ich Daten, indem sie auf das RDBMS kommen.

Übrigens würde ich mich freuen, wenn irgendwer in Konfigurationsdaten rumfummelt. Das gibt nämlich dann eine saftige Rechnung!

Ich kenne nur keinen Fall, wo ich File-of-record einem Stream vorziehen würde. Aber vermutlich, weil ich nicht mit Records arbeite, keine Shortstrings verwende, sowie keine einfachen Strukturen habe.

Jedem das Seine, würde ich da sagen.

[Sir Rufo]

Irgendwie habe ich diesen Thread so verstanden, dass Daten von einem alten Delphi-Programm eingelesen werden sollen.

Im neuen Programm würde ich auch auf aktuelle Strukturen setzen (Datenbank, XML, etc. bzw. Klassen statt Records) aber den Zugriff auf diese alten Daten mit einem Adapter-Pattern und dem file of record (in einem Strategy-Pattern) realisieren.

[Der schöne Günther]

Richtig, eigentlich wollte ich nur wissen, ob ich Legacy-Daten, die ebenso geschrieben wurden, auch wieder so einlesen kann. Ob das Konzept mit dem "File" heute Probleme bei Dingen wie Rechten, Netzwerkpfaden, Überschreitung von Dateigrößen oder Sonderzeichen mit sich bringt.

Aber ein bisschen weiterführende Diskussion schadet ja nicht :chat:

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1223351)

Richtig, eigentlich wollte ich nur wissen, ob ich Legacy-Daten, die ebenso geschrieben wurden, auch wieder so einlesen kann. Ob das Konzept mit dem "File" heute Probleme bei Dingen wie Rechten, Netzwerkpfaden, Überschreitung von Dateigrößen oder Sonderzeichen mit sich bringt.

Aber ein bisschen weiterführende Diskussion schadet ja nicht :chat:

weiterführend ja, aber irgendwie galoppierten die Pferde auf einer ganz anderen Koppel :mrgreen:

Probleme in diesem Kontext sind mir dazu nicht bekannt.

[Furtbichler]

Zitat:

Zitat von Sir Rufo (Beitrag 1223352)

Zitat:

Zitat von Der schöne Günther (Beitrag 1223351)

Aber ein bisschen weiterführende Diskussion schadet ja nicht :chat:

weiterführend ja, aber irgendwie galoppierten die Pferde auf einer ganz anderen Koppel :mrgreen:

Bischen OT schadet nie.

Im Ernst: Ich bezweifle, das eine in Turbo-Pascal geschriebene Datei unter Delphi noch als File-Of-Record ausgelesen werden kann. Nicht das weiß, das es nicht geht, ich bin einfach nur unsicher. Daher würde ich das happenweise einlesen, einfach, um auf Nummer sicher zu gehen. Ich meine mich nämlich zu erinnern, das der 'packed record' nicht mehr ganz so gepackt ist, wie früher (oder war es das packed array?)

[Namenloser]

Zitat:

Zitat von Furtbichler (Beitrag 1223358)

Im Ernst: Ich bezweifle, das eine in Turbo-Pascal geschriebene Datei unter Delphi noch als File-Of-Record ausgelesen werden kann.

Was sollte dagegen sprechen? Nur wenn Datentypen wie Integer im Record vorkommen, die früher mal 16bit groß waren und heute 32, müsste man aufpassen.

Ansonsten gilt: Packed ist packed... sonst wäre das ja komplett sinnlos.

[Furtbichler]

Zitat:

Zitat von NamenLozer (Beitrag 1223366)

Zitat:

Zitat von Furtbichler (Beitrag 1223358)

Im Ernst: Ich bezweifle, das eine in Turbo-Pascal geschriebene Datei unter Delphi noch als File-Of-Record ausgelesen werden kann.

Was sollte dagegen sprechen? Ansonsten gilt: Packed ist packed... sonst wäre das ja komplett sinnlos.

verschachtelte packed records sind nicht mehr byte-aligned, soweit ich mich erinnere.

[p80286]

Bis D2006 gib's da keine Probleme.

Gruß
K-H

[Furtbichler]

Doch, leider ja. Habe hier ein Beispiel, ist aber closed source: packed records mit packed arrays und short strings. 'packed array of boolean'. An einer Stelle muss mittlerweile ein zusätzliches Byte rein (zum Auffüllen).

Ergo: Ist meistens kompatibel, aber unterschreiben würde ich es nicht.

Daher schreibe ich explizite Lese- und Schreibroutinen für Records. Wenn ich sie denn noch benutze.

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1223398)

'packed array of boolean'.

Soweit ich weiß, hat sich Boolean genauso wie Integer, String... geändert.
Langer Diskussion kurzer Sinn "Es spricht nichts dagegen sie zu nutzen, wenn man weiß was man tut"
Es gibt in der Zwischenzeit Formate, die nicht so fehleranfällig sind.

Gruß
K-H

[Namenloser]

Zitat:

Zitat von Furtbichler (Beitrag 1223398)

Doch, leider ja. Habe hier ein Beispiel, ist aber closed source: packed records mit packed arrays und short strings. 'packed array of boolean'. An einer Stelle muss mittlerweile ein zusätzliches Byte rein (zum Auffüllen).

Ergo: Ist meistens kompatibel, aber unterschreiben würde ich es nicht.

Daher schreibe ich explizite Lese- und Schreibroutinen für Records. Wenn ich sie denn noch benutze.

Das halte ich dann allerdings für einen Bug des Compilers.

[Furtbichler]

Zitat:

Zitat von NamenLozer (Beitrag 1223412)

Das halte ich dann allerdings für einen Bug des Compilers.

Na und? Ändert nichts daran, das es nicht funktioniert.

[jaenicke]

Zitat:

Zitat von NamenLozer (Beitrag 1223412)

Das halte ich dann allerdings für einen Bug des Compilers.

Wo steht denn dokumentiert, dass sich die Strukturen von packed records nicht auch mal ändern? So weit ich weiß nirgends. Dementsprechend kann man sich dann eben auch nicht darauf verlassen, sonst ist man halt ggf. verlassen...

Wenn es funktioniert, ist es gut, für neue Projekte gibt es verlässlichere Lösungen.

[Mavarik]

Zitat:

Zitat von Furtbichler (Beitrag 1223370)

Zitat:

Zitat von NamenLozer (Beitrag 1223366)

Zitat:

Zitat von Furtbichler (Beitrag 1223358)

Im Ernst: Ich bezweifle, das eine in Turbo-Pascal geschriebene Datei unter Delphi noch als File-Of-Record ausgelesen werden kann.

Was sollte dagegen sprechen? Ansonsten gilt: Packed ist packed... sonst wäre das ja komplett sinnlos.

verschachtelte packed records sind nicht mehr byte-aligned, soweit ich mich erinnere.

{$A1}

Und schon bin ich kompatible zu TP

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1223563)

...{$A1} Und schon bin ich kompatible zu TP

:thumb: Das wäre ein Möglichkeit gewesen. Aber dann hätten andere Dinge vielleicht nicht funktioniert. Ich bin ein gebranntes Kindr Greis und trau dem nicht mehr über den Weg.