TurboPower B-Tree Filer

[Jasocul]

Ich hoffe, ich erinnere mich richtig. Dürfte ca 20 Jahre her sein.
Die Dateien haben einen Header und dann kommen die Daten. Die Header-Größe weiß ich nicht mehr, aber das dürfte kein Problem sein. Ich würde das ganze mit Blockread verarbeiten.
Die Daten kannst du ganz normal in einen Record mit passender Struktur einlesen. Achte darauf, dass du keine Ausrichtung an Speichergrenzen eingestellt hast. Das ist in Delphi nämlich die Standard-Einstellung und führt beim Einlesen mit Blockread zu Verschiebungen der Daten im Record. Wie der Compiler-Schalter genau heißt, kann ich dir aus dem Kopf nicht sagen. Wie weiter üben schon geschrieben wurde, sind die ersten 4 Byte (ich glaube das war unter TP Integer) der Bereich, wo interne Infos von BTree gespeichert wurden (z.B. Löschkennzeichen).
Ich habe zu hause sogar noch die passende Software. Müsste ich allerdings erst suchen.

[Playwitch]

Hallo,

da bin ich wieder.
Vielen Dank für die vielen und schnellen Tipps!
Die Sache mit den Integer- und Real-Unterschieden zwischen TP und Delphi könnte das Problem erledigen. Ich werd's gleich mal ausprobieren.

Trotzdem hänge ich (vor allem für Hansa) mal eine sehr kleine .DAT-Datei an (da hier .Dat als Endung verboten ist, habe ich sie in .txt geändert) und zeige hier die entspr. Datendefinition:

Delphi-Quellcode:

Const BLEIFDatSLen:Word=22;
Type
  BLEIFDatSType=Record
    _DelMark:LongInt;   {ReservedCType;offset=0}
    _AutoRel:LongInt;   {LongIntCType; offset=4}
    SACHNR  :String[9]; {StringCType;  offset=8}
    PREIS   :Single;    {SingleCType;  offset=18}
  End;

Die beiden LongInt am Anfang brauche ich nicht; der String kommt wunderbar, aber der Single geht in die Hose. Es wird ein Wert bei 10^-41 angezeigt, vermutlich zufällig.

Beste Grüße
Holger

[Hansa]

Aha, glasklarer Fall. Warum nicht gleich. 8) Ich dachte die Datenstruktur wäre unbekannt ? Die ersten 4 byte sind ein 16-Bit longint, also bei Win32 ein integer. Die nächsten 4 Byte sind auch ein longint, jetzt also auch integer. Offset=8 heißt : das beginnt beim 9. Byte. Das _ vor den Feldnamen bedeutet so in der Richtung "Systemfeld". Also : Finger weg für User. Denn : die ersten 4 byte als longint sind ein "gelöscht" Flag. 0 heißt : nicht gelöscht. <> 0 eben gelöscht. Werden die Indexdateien gelöscht, dann wird die Datenbank davon bereinigt. Das nächste longint ist wie man heute sagen würde, eine fortlaufende ID der Datensätze. Oder "Autoincrementfeld". Für Fremdschlüssel usw. Tja das wars. Bleibt nur noch single übrig. Zufällig ist da übrigens nichts. 18 Byte sind geklärt. Also teile jetzt mal die Dateigröße durch 19 bis 30. Es muß ein ganzzahliger Wert rauskommen. Und wie immer : zuert mal F1 drücken.

[Playwitch]

Hallo,

erstmal bitte ich um Entschuldigung, dass ich nicht gleich von LongInt und Single geschrieben habe!

Dann sehe ich nun bei meinen Recherchen, dass diese beiden Typen allerdings in TP/DOS wie in Delphi/Win32 dieselben Speichergrößen haben. Jetzt ist mir das wieder ein Rätsel.

Und nun zu Hansa:
Zunächst schon mal danke für deine Mühe!
Hier ist das was eigentlich in der Tabelle ist. Wieder entschuldigung! Hätte ich auch gleich beifügen können. Man vergisst in der Hektik aber schnell mal was. Vor allem wenn alle Jahre mal was postet.

Es handelt sich um 2 Datensätze mit folgenden Werten für den String und den Single:

1.) "004" und "223,10"
2.) "004004004" und "368,10"

Das ist das, was das alte Programm anzeigt.

Der Single dürfte mit 4 Byte zu Buche schlagen, somit wären wir bei 22 Byte.
Bei 2 Datensätzen (sind es definitiv) bleiben wir bei 44 Bate, bleiben also 22 andere übrig.
Ich meine, irgendwo im Handbuch gelesen zu haben, dass ein erster Datensatz für interne Verwendung reserviert ist. Das würde es erklären.

Nun habe ich aber die Datenstruktur und die 4 Byte Größe des Single, doch bekomme ich immer noch nicht meine richtigen Zahlen!
Woran kann's denn liegen?

Gruß
Holger

[Jasocul]

Und wenn du meinen Hinweis gelesen hättest, hättest du auch keine Probleme genau diesen Record zu benutzen.
Die Felder des Records müssen ausgerichtet sein. Dafür benötigst du eine Compiler-Direktive: {$A-}
Ich habe es getestet und ich kann die Datei korrekt verarbeiten.

[Playwitch]

Das ist es!!!

Vielen Dank, Peter (Jasocul)!
Einfach den Compilerschalter {$A-} gesetzt und die Sache läuft! Alle Zahlen sind richtig! Super!
Über den $A-Schalter war mir bisher nichts bekannt.

Entschuldige, dass ich auf deinen ersten Beitrag nicht entsprechend reagiert habe, aber ich hatte es einfach nicht verstanden, wie das gemeint war mit dem Blockread, der Ausrichtung an Speichergrenzen und der Verschiebung der Daten im Record.
Jetzt ist mir die Sache aber klar. Hätte auch nicht gedacht, dass es eine solch begrenzende Voreistellung gibt.

Und nochmal vielen Dank an die anderen, die mir geantwortet haben!

Beste Grüße
Holger

[Jasocul]

War auch nicht böse gemeint.
Ich kenne das Problem nur von einer eigenen Anwendung, wo ich Spiele-Dateien verändere.
Dort musste ich mit Blockread arbeiten.

Ursache des ganzen:
In Turbo-Pascal waren packed-Records der Standard um RAM zu sparen. Das ist heutzutage nicht mehr erforderlich. Daher wird das nicht mehr gemacht und nutzt zur Geschwindigkeitssteigerung die Ausrichtung im Speicher. So war zumindest mal die Info, die ich bekommen hatte.