alte Datenbankdatei einlesen und weiterverarbeiten

**hronny**

Moin!

Ich habe eine alte Datenbankdatei, wobei ich nicht weis was für ein Typ das ist. Nun dachte ich, da es eine Binärdatei ist, das ich die via Stream einlese und weiterverarbeite. Herausgefunden habe ich schon das die eigentlichen "Datensätze" ab Byte 260 anfangen und dann immer 256 Byte lang sind. Nur weis ich nicht so richtig wie ich das machen kann. Trennzeichen zwischen den Daten scheint ein NULL zu sein. Da die einzelnen Daten unterschiedlich lang sind kann ich (glaub ich) kein Record nehmen. Mein Gedankengang sieht so aus:

zusammenfalten · markieren

Delphi-Quellcode:

			var

  Stream: TStream;

begin

  Stream := TFileStream.Create('ANSCHR.DAT',fmOpenRead);

  Stream.Position:=260;

  try

    Stream.Read(Len, 256);

    // Wie geht es weiter?

  finally

    Stream.Free;

  end;

end;

**alzaimar**

Du musst doch wissen, wie man die einzelnen Daten extrahiert. Vielleicht steht da erst 2 byte Länge, dann eine entsprechende Menge an Zeichen (das wäre ein String), danach ein INTEGER (4 Byte)... ohne Analyse wirst Du da nicht viel machen können...

Besorg Dir einen Hex-Viewer, der hilft Dir vielleicht weiter.

**hronny**

Ja die Struktur ist Relativ einfach

zusammenfalten · markieren

Delphi-Quellcode:

			00000000h: 00 00 00 00 31 30 30 30 33 00 00 00 00 4B 75 6E ; ....10003....Kun

00000010h: 64 65 6E 6E 61 6D 65 20 75 6E 64 20 62 65 7A 65 ; denname und beze

00000020h: 69 63 68 6E 75 6E 20 6D 69 74 20 45 78 74 72 61 ; ichnun mit Extra

00000030h: 74 65 78 74 20 00 53 74 72 61 DF 65 6E 6E 61 6D ; text .Straßennam

00000040h: 65 20 6D 69 74 20 4E 75 6D 6D 65 72 00 00 50 4C ; e mit Nummer..PL

00000050h: 5A 20 75 6E 64 20 4F 72 74 20 20 20 00 00 00 30 ; Z und Ort   ...0

00000060h: 31 32 33 34 2F 35 36 37 38 39 30 00 30 31 32 33 ; 1234/567890.0123

00000070h: 34 2F 35 36 37 38 39 31 00 00 00 00 00 00 00 00 ; 4/567891........

00000080h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000090h: 00 00 00 00 00 00 00 00 00 0A 00 00 00 00 00 00 ; ................

000000a0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FB ; ...............û

000000b0h: 85 83 24 00 00 00 00 00 00 53 B4 83 24 00 00 00 ; …ƒ$......S´ƒ$...

000000c0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000d0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000f0h: 00 00 00 00 00 00 00 00 00 00 90 00 00 00 00 00 ; ..........�.....

00000100h: 00 00 00 00 31 30 30 30 35 00 00 00 00 4D 41 5A ; ....10005....MAZ

und eigentlich geht es mir nur um den Text.

**Hansa**

Wieso fangen die Daten angeblich erst bei Byte 260 an ?

Im Datenfragment sehe ich jedenfalls folgendes : Der Abstand von 10003 zu 10005 beträgt 16 Zeilen zu je 16 Zeichen = 256 Byte. Was steht jetzt oben im Klartext drin ? Ich nehme mal an, Du warst schlau und hast im Originalprogramm einen Datensatz angelegt, um die Felder zu identifizieren. Kann das so sein ?

P.S.: ist das Original-Programm verfügbar, oder nur die Daten ?? Ersteres würde einige Fragen beseitigen.

**alzaimar**

Wir raten: Das, was wir sehen, sind die Spaltenüberschriften.
- Vorne stehen 4 Nullen und 10003#0.
- Kundenname mit Extratext endet mit einem Leerzeichen, Straßenname mit Nummer auch, aber die PLZ mit drei Leerzeichen.
- Jede 'Spaltenüberschrift' wird mit einem #0 abgeschlossen und auf eine gerade Anzahl von Bytes aufgefüllt.

Hansa könnte durchaus Recht haben. Und der Rest von den ersten 256 Bytes ist einfach irgendwelcher Müll...
Du solltest Dir die nächsten Records anschauen, denn der erste endet ähnlich, wie der zweite angefangen hat. (10003___Kun vs. 10005___MAZ)

Ich gehe mal davon aus, das Du in den nächsten Records eine ähnliche Struktur feststellen wirst. Wenn die 'Records' variabel sind, dann liegt das an den Strings mit variabler Länge.

Der BTree-Filer hat z.B. per definitionem in den ersten 4 Bytes eines Records (gabs auch mit variabler Länge) eine 00 00 00 00, wenn der Record gültig war und etwas Anderes, wenn der Record gelöscht wurde (repack musste man manuell durchführen).

Letztendlich ist das Spiel 'zeig mir eine Datei und ich sag Dir was drin ist' mur mit Versuch und Irrtum zu lösen. Und viel Nachzählerei.

**hronny**

Zitat von Hansa:

Wieso fangen die Daten angeblich erst bei Byte 260 an ?

Ja ich wollte nicht die ganze orginaldatei posten. Deshalb war es nur ein auskopierter Abschnitt. Hier nochmal der komplette Dateianfang (die Daten habe ich manuell verändert aus Datenschutzgründen)

zusammenfalten · markieren

Delphi-Quellcode:

			00000000h: FF FF FF FF 00 00 00 00 9D 06 00 00 00 01 00 00 ; ÿÿÿÿ...........

00000010h: 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000020h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000030h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000040h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000050h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000060h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000070h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000080h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000090h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000a0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000c0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000d0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000000f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000100h: 00 00 00 00 31 30 30 30 30 00 00 00 46 69 72 6D ; ....10000...Firm

00000110h: 61 00 44 69 70 6C 2E 2D 49 6E 67 2E 20 57 61 6C ; a.Dipl.-Ing. Wal

00000120h: 74 65 72 20 57 65 72 6E 65 72 00 53 6F 6E 64 65 ; ter Werner.Sonde

00000130h: 72 65 69 6E 72 69 63 68 74 75 6E 67 65 6E 00 4D ; reinrichtungen.M

00000140h: 75 73 74 65 72 73 74 72 61 73 73 65 20 32 2E 20 ; usterstrasse 2. 

00000150h: 34 00 00 31 32 33 34 35 20 57 6F 68 6E 6F 72 00 ; 4..12345 Wohnor.

00000160h: 00 00 30 31 32 33 34 35 36 37 37 38 39 00 30 31 ; ..01234567789.01

00000170h: 32 33 34 35 36 35 37 38 39 00 00 00 00 00 00 00 ; 234565789.......

00000180h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

00000190h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000001a0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000001c0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000001d0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000001e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000001f0h: 00 00 00 00 00 00 00 00 00 00 91 00 00 00 00 00 ; ..........‘.....

00000200h: 00 00 00 00 31 30 30 30 31 00 00 00 00 54 65 63 ; ....10001....Tec

00000210h: 68 6E 69 6B 20 75 6E 64 20 54 65 73 74 47 62 48 ; hnik und TestGbH

00000220h: 00 4E 69 65 64 65 72 6C 61 73 73 75 6E 67 20 54 ; .Niederlassung T

00000230h: 68 FC 72 69 6E 67 65 6E 00 4D 75 73 74 65 72 6D ; hüringen.Musterm

00000240h: 61 6E 6E 6F 64 61 65 72 20 53 74 72 61 DF 65 20 ; annodaer Straße 

00000250h: 34 00 00 31 32 33 34 35 20 4D 75 73 74 65 72 73 ; 4..12345 Musters

00000260h: 74 61 73 64 74 75 6E 64 6F 72 74 00 00 00 30 32 ; tasdtundort...02

00000270h: 33 34 35 36 2F 37 38 39 30 31 00 30 32 33 34 35 ; 3456/78901.02345

00000280h: 36 2F 37 38 39 30 31 00 00 00 00 00 00 00 00 00 ; 6/78901.........

00000290h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000002a0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FB ; ...............û

000002b0h: 85 83 24 00 00 00 00 00 00 53 B4 83 24 00 00 00 ; …ƒ$......S´ƒ$...

000002c0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000002d0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000002e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

000002f0h: 00 00 00 00 00 00 00 00 00 00 9F 00 00 00 00 00 ; ..........Ÿ.....

00000300h: 00 00 00 00 31 30 30 30 32 00 00 00 00 41 72 6E ; ....10002....Arn

Das Programm ist nicht mehr lauffähig, und die Installationsdiskette ist defekt. Was Ihr geraten habt (Straße usw), denke ich auch das es so sein muß. Nur weiß ich nicht wie man das umwandelt.

**Hansa**

Zitat von hronny:

..Trennzeichen zwischen den Daten scheint ein NULL zu sein. Da die einzelnen Daten unterschiedlich lang sind kann ich (glaub ich) kein Record nehmen. Mein Gedankengang...

Papperlapapp.

Ein Trennzeichen zwischen den Datensätzen wird doch überhaupt nicht gebraucht. Warum ? Die Datensätze sind gleich lang. Genau 256 Bytes. Das reicht. Am Anfang fängts allerdings tataächlich mit 260 Bytes an. Das sind 256 + 4. 4 Bytes sind in 16-Bit Systemen ein Pascal longint. Am Anfang deutet darauf hin, dass es die Anzahl der Datensätze enthält. Dann kommt ein leerer Datensatz und es geht immer schön in Schritten zu 256 Byte weiter von Datensatz zu Datensatz. Alzaimar hat die 4 führenden Bytes bemerkt. Sieht so aus, als hätte er Recht. Meine Glaskugel hat hieraus folgenden Daten-Record hergestellt :

zusammenfalten · markieren

Delphi-Quellcode:

			(*$ ??+ 16 Bit Compiler-Direktive *)

type 

  Daten = record

    geloescht : longint;

    Nr : string [5];

    Name1,

    Name2,

    Strasse,

    Ort : string [??];  // wegen "Datenschutz" wohl fehlerhaft Daten verändert Schätze: ??=20 oder 25

    frei : array [??];  // Differenz an Bytes bis 256 Zweck unbekannt. ?? abhängig von obigen strings

  end;

**Jürgen Thomas**

Hallo,
ich muss mich mit einem ähnlichen DOS-Format (Adad9) befassen. Die Daten-Datei sieht ähnlich aus; außerdem gibt es eine DAD (Datei-Definition), in der die Felddefinitionen enthalten sind: Feldnamen, Reihenfolge, maximale Feldlänge. Gibt es bei Dir auch solche Zusatzdateien?

Nach meiner o.g. Erfahrung kann ein Datensatz auch mehrere Blöcke à 256 Bytes lang sein. Es fragt sich dann, wo bzw. wie die anderen Informationen zu finden sind. Ich schlage deshalb vor, auf "Nummer Sicher" zu gehen und doch mit Feld- und Satztrenner zu arbeiten:

Dateianfang ist klar: ein leerer Datensatz, der mit 4x FF beginnt.
4x 00 ist Anfang eines Datensatzes.
1x 00 ist Ende eines Datenfeldes.

Daraus entnehme ich:

1. Adressennummer
2, 3. In den Beispielen folgen zwei Felder ohne Inhalt.
4. Anrede
5. Name
6. Namenszusatz
7. Straße
8. unbekanntes Feld
9. PLZ + Ort
10, 11. zwei unbekannte Felder
12, 13. Telefon, Telefax

In dieser Weise musst Du die Datei möglichst insgesamt ansehen und alle möglichen Felder interpretieren. Dann kannst Du bearbeiten:

Erzeuge eine Struktur (Record, Klasse o.ä.) mit allen tatsächlich möglichen Feldern (ähnlich dem Vorschlag von Hansa). Benutze am besten String (variable Länge gemäß Delphi) für Textfelder, damit Du keine Probleme mit der max. Feldlänge bekommst.
Lies die Datei als Stream ein.
Gehe an Position 256.
Bearbeite danach jeden Datensatz; prüfe den Satzanfang.
Bearbeite danach alle Felder: Merke Dir die Position des Feldanfangs, gehe bis zum nächsten Feldtrenner und kopiere den Feldinhalt usw. - bei Bedarf mit StrToIntDef usw. Berücksichtige dabei, dass ein Feldinhalt nur aus dem Feldtrenner bestehen kann.

Ich bin gerne bereit, Dir bei der weiteren Analyse der Datei zu helfen. Jürgen

**alzaimar**

Hansa, das mit dem Record klappt nicht, denn die Strings sind unterschiedlich lang (Null-Begrenzung und 16-Bit Ausrichtung). Mein Ansatz würde so lauten, das man immer 256 Bytes einliest und dann mit die Null-Terminierten Strings einliest. Nach erreichen der Null zum nächsten geraden Offset springen und den nächsten String einlesen. Dann zum nächsten 256-Byte Record etc.

Mal sehen was da rauskommt. Im Zweiten Schritt die Records analysieren, die so nicht passen, Vielleicht ist die Record-ID (die ersten 4 Bytes) etwas mehr als ein 'gelöscht/nicht gelöscht'...

**marabu**

Hi,

ist schon geklärt um welches Programm es sich ursprünglich handelte? Warum läuft es nicht mehr? War das ein Fremdprodukt, von der Stange oder eine Auftragsarbeit? Ist der Hersteller nicht mehr greifbar um die Installations-CD zu ersetzen? Gibt es keine Aufzeichnungen zum Datenformat? In welcher Sprache wurde es implementiert? Handelt es sich um einen flat file oder wirklich um eine Datenbank-Datei?

u.s.w.

Freundliche Grüße vom marabu