TurboPower B-Tree Filer

[Playwitch]

Hallo,

kennt jemand den B-Tree Filer von TurboPower?

Ich habe alte B-Tree Daten, die von einem TurboPascal-Programm unter DOS stammen. Die Datenbank-Software hieß damals noch B-Tree Isam von ENZ EDV-Beratung, wurde später von TurboPower übernommen und heißt jetzt B-Tree Filer.

Nun möchte ich daraus in Delphi 5 Daten auslesen, um sie in einer anderen Datenbank zu speichern.
Das geht soweit ganz gut, aber die Zahlenwerte, Float und Integer, werde falsch ausgelesen.

Kennt sich jemand aus und kann mir helfen?

Holger

[mikhal]

TurboPower hat alle seine Projekte OpenSource gestellt, nachdem die Firma aufgelöst wurde.

Hier findest du alles, was zu B-Tree-Filer freigegeben wurde.

Grüße
Mikhal

[Hansa]

Zitat:

Zitat von Playwitch

...aber die Zahlenwerte, Float und Integer, werde falsch ausgelesen...

Aha. Also falsch ausgelesen ? Was soll das jetzt irgendwem sagen ?

[Playwitch]

Hallo Mikhal,
kenne ich und die Sachen habe ich schon. Trotzdem danke!

Hallo Hansa,
mit falsch ausgelesen meine ich, dass ein ein scheinbar nicht gültiger Wert gelesen wird. Wenn ich das in einer MessageBox ausgeben lasse oder beim debuggen anzeigen lasse, erscheint irgendwas mit 10^-41 oder so.
In der DOS-Version stehen aber an diesen Stellen echte Werte, z. B. Preise.

Meine Frage geht dahin, ob jemand schon mal das gleiche Problem hatte, oder ob jemand weiß, ob es zwischen der alten DOS-Version und dem B-Tree Filer einen Unterschied im Datenformat in den .dat-Dateien gibt.

Grüße
Holger

[Hansa]

Du mußt Teile der Daten zeigen. Vorher kann man kaum was sagen. Wie lange sind denn die Datensätze ?

[alzaimar]

HSuch dir einfach ein altes TP7 und schreib einen BTreeFiler-zu-DBF Konverter. So ein Teil ist wirklich schnell geschrieben.

Prinzipiell ist eine BTreeFiler-Datenbank einfach als "File Of TBlock", wobei TBlock ein Record, bestehend aus 4 Bytes Header und deinem Record. Der Header gibt an, ob der Datensatz gelöscht ist, oder nicht (glaub ich).

Schau Dir doch die Datei einfach mal mit einem Hex-Editor an, dann sieht man doch, wo es hakt.

[webcss]

ich hatte mal ein ähnliches problem so gelöst: unter tp die BTreeFiler daten einfach in string konvertiert und in einer Textdatei gespeichert(delimited), danach das textfilein delphi in meine zieldatenbank konvertiert. soweit ich weiss gibt est die Opensourceversion auch für windows (TP f.Windows zumindest) du kannst dir aber deinen eigenen Record zusammenbauen (aufgrund des Aufbaus wie du ihn im source findest) und direkt konvertieren. Du musst dabei nur bedenken das z.b. integer damals nur 16bit breit waren und heute 32 bit(damals longint) bzw 64bit (damals fehlanzeige). daran kanns liegen, das du falsche werte bekommst. :wink:

[Hansa]

Er soll einen Datensatz posten, oder eine kleine DAT anhängen. Notfalls frage ich Enz. :mrgreen:

[jbg]

Zitat:

Zitat von Playwitch

Das geht soweit ganz gut, aber die Zahlenwerte, Float und Integer, werde falsch ausgelesen.

Das ein Integer unter TurboPascal nur zwei Byte und unter Delphi (ab Version 2) vier Bytes hat, weißt du?

[Ghostwalker]

Ja..ich schätze das du die Datentypen falsch definiert hast.

Wie bereits oben erwähnt, solltest du für alte Daten statt den delphi-Integer (32-Bit) den alten
Smallint (16-Bit) verwenden, das sollte klappen.

Desweiteren mußt du auf die Real-Werte achten. Der Datentyp Float wird unter Delphi für API-Calls
verwendet und ist in der Regel extended. Für alte DOS-Daten solltest du den Datentyp Real bzw. Real48
verwenden.


Hoffe das Hilft dir weiter :)

[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". :zwinker: 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. :duck:
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.