Datenstruktur erkennen Turbo Pascal Dos mit Toolbox(4)

[grl]

Hmmm - ich hab mal irgendwo gelesen, daß die Filestruktur vom TurboPower BTree Filer übernommen wurde - der ist via Sourceforge noch zu kriegen.

Vielleicht kann man damit die Dateien lesen?

GRL

[Furtbichler]

grl: BTree-Filer verwendet genau das im Handbuch (und von mir) beschriebene Format (also ein File of TDataRecord). Das Problem ist der Aufbau von 'TDataRecord'. Das muss man rausbekommen.

[MeierZwoo]

Zitat von einseins:

Leider ist der Aufbau der Datendatei eindeutig ,

Wieso "leider"? Ein eindeutiger Aufbau einer Datendatei ist doch kein Manko, im Gegenteil.

Und es ist richtig, daß die DataToolbox durch BTree-Isam abgelöst wurde, diese dann als "Filer" übernommen und inzwischen der Quellcode freigegeben wurde. Der Quellcode muß aber angepaßt werden, da er nur bis Delphi 2007 unterstützt. Nur ist das eh egal, da ja wohl eine Konvertierung zu einem neuen Programm vorgenommen werden soll, also aus den reinen Datendateien Die Datensätze ausgelesen und einem neuem Programm (konvertiert) zur Verfügung gestellt werden sollen. Die Indexdateien kann man dabei getrost vergessen, weil deren Struktur zu ermitteln ohne Quellcode und den darin beschriebenen Indexparametern so gut wie unmöglich ist.

Ich würde erstmal einen 32bit PC sicherstellen, damit auch später noch von vorh. Daten eine Aktenlage (auf Papier) hergestellt werden kann (ab 64bit gibt es keine DOS-VM mehr). Dann zum Jahreswechsel mit Jahresabschluß die Aktenlage herstellen.

Bei dem Wust an Dateien (s. rar) viel Zeit nehmen oder die weitergeführten Stamm-Daten, wie z.B. Kunden/Mandanten/Lager/Waren-Parameter einfach von Ausdrucken oder dem alten Programm selbst in das neue Programm eintippseln.

@einseins, wenn du die Datendateien wirklich auslesen und konvertieren willst, beachte auch, daß nicht alle Datensätze einer Datei gleich aufgebaut sein müssen - nur ihre Gesamtlänge [byte] ist wohl gleich, aber auch nicht komplett benutzt.

Die Datendateien bestehen aus einem Header (erster Satz, Rec 0), in dem vier Parameter, drei Longint und ein Word stehen. Diese geben
a) FirstFree:longint (RecNr des ersten gelöschten Recs)
b) NumFree:longint (Anzahl der gelöschten Recs)
c) UsedRecs:longint (Anzahl Recs ohne Rec0 und ohne gelöschte/ungültige Recs
d) Reclen:word
an. Daraus interessiert beim Auslesen der Daten ansich nur RecLen, wiel diese der Record-Größe zum deklarieren der Datei oder dem Lesepuffer entsprechen muß.

Wie oben schon gesagt (Furtbichler) besteht jeder Datensatz aus einem Longint (4 Byte) und den nachfolgenden Daten. Der Longint zählt mit zum RecLen und zum zu deklarierenden Record/Puffer. Ein Datensatz ist nur gültig, wenn diese ersten vier Byte alle Null sind - ansonsten gilt er als gelöscht und der Longint ist ein Zeiger auf den nächsten, gelöschten Datensatz. Aber das sollte auch in dem vorher schon verlinkten Handbuch stehen (?).

Die spezielle Struktur eines Datensatzes ermittelt man am besten, in dem man mit dam Anwenungsprogramm Daten anlegt; möglichst einedeutig wiedererkennbar und dann in den Datendateien nach diesen Daten sucht (z.B. mit einer Hilfsroutine oder einem HexEditor). Und dann daraus die jeweiligen Records ermittelt.

FF (Fiel Freude), ich hoffe, Du wirst gut bezahlt.

[einseins]

Oh das klingt sehr gut . Ganz herzlichen Dank an alle die mir diese Informationen zur Verfügung gestellt haben . Ich werde nun erst mal die nächste Zeit nutzen und Datenanalyse machen . Eines habe ich schon herausgefunden . Das Programm legt jede Rechnung und Lieferschein usw.. in eine eigene Datei ab . Sicher könnt ihr euch vorstellen wie viele Dateien das sind (Seit 1990) . Man kann sagen der Irrsinn nimmt seinen Lauf. Falls eine der Dateien fehlt löschen oder defekt wird eine Fehlermeldung gebracht und das Programm beendet seinen Dienst. Gut eine kleine Frage bleibt aber noch: Zahlen und oder Beträge oder Mengenangaben wie diese abgelegt werden oder wurden ,da es dennoch Bereiche im Datensatz gibt die ich nicht ohne weiteres zuordnen kann.
Na ich versuche mal mein Glück und Danke

[himitsu]

Ideal währe es ja, wen für Geldbeträge Currency als Datentyp verwendet wurden (das ist praktisch ein Int64, welcher durch 10000 geteilt wird, bzw. stat 12,34 steht dann 123400 im Speicher), oder irgend ein BCD-Format (aber das glaub ich weniger), um Rundungsfehler auszuschließen.
Ansonsten bleiben ja nur noch Single oder Double (oder Extended und hoffentlich kein Comp).

Ich lege dir da gern den HxD ans Herz. Dieser Hexeditor zeigt dir gern an, was in den markierten Bytes drinstehen würde und du kannst nachsehn, ob das zu irgendeinem Feld passt.

[MeierZwoo]

Zitat von einseins:

Gut eine kleine Frage bleibt aber noch: Zahlen und oder Beträge oder Mengenangaben wie diese abgelegt werden oder wurden

Siehe: "Die spezielle Struktur eines Datensatzes ermittelt man am besten, in dem man mit dam Anwendungsprogramm <eindeutige, wiedererkennbare> Daten anlegt;"
Und diese Werte (Zahlen, Beträge) dann in den Datensätzen wiederfinden - unter testen mit allen alten TP-Typen.

Zitat von einseins:

...da es dennoch Bereiche im Datensatz gibt die ich nicht ohne weiteres zuordnen kann.

Ohne Quellcode wird es immer Bereiche geben, bei denen man nur raten kann bzw. es wohl nie erkennen wird, z.B. Marker / Flags ...

[einseins]

Es gibt eine interessante Info noch . Zu diesem Programm gibt es ein Handbuch wo man vieles erklärt bekommt . Als Beispiel kann man die Buchungsdatei exportieren (als Dbase ist aber ein optionales Modul gewesen ) Dort beschrieben sind folgende Datenfelder bei der Ausgabe angegeben . Wenn ich mir die Buchv4.6 ansehen sieht es fast wie diese Struktur aus .

[MeierZwoo]

Zitat von himitsu:

...und hoffentlich kein Comp

Wieso? Comp war (und ist) nach BCD der angesagteste Type für Geldbeträge, zumal die alten TP-Versionen über einen x87-Emulator verfügten.

[OlafSt]

Zu DOS-Zeiten waren Datentypen wie Comp oder Extended völlig unbekannt. Da wurde mit Real gearbeitet, dem emulierten 6-Byte-Float.

Ich stand selbst mal davor, so ein selbstgestricktes Datenformat von Turbo-Pascal DOS analysieren und konvertieren zu müssen. Einige Teile habe ich in den einzelnen Dateien wiedererkannt, aber es sind auch ebenso viele unbekannte Elemente da drin, die ein schnelles basteln eines Konverters schier unmöglich machen.

[Edit] Das PDF ist äußerst aufschlußreich, da ließe sich womöglich was mit Anfangen. Welche von den vielen einzelnen Files im RAR ist eine Buchungsdatei ?

[MeierZwoo]

Zitat von OlafSt:

Zu DOS-Zeiten waren Datentypen wie Comp oder Extended völlig unbekannt.

Stimmt ja nun hinten und vorne nicht. Das TP 4.0 Handbuch (1987) weist Comp, Extended, Single, Double als x87 Typen aus - dafür gab es, wie oben schon gesagt, auch den x87 Emulator, wenn kein x87 als Hardware vorhanden war (bis incl. i386 war eine CoCPU zusätzlich nötig, ab i486 war die CoCPU in der CPU integriert).

Ich bin zu faul in den Keller zu gehen, um in noch älteren Handbüchern deswegen nachzuschlagen, 1987 sollte als "alt" und "DOS-Zeiten" reichen.