.dbf-Datei identifizieren

[diwa]

Hi Leute,

vor ewigen Zeiten habe ich recht viel mit Clipper programmiert - aber irgendwie nie den Sprung auf eines der diversen System unter Windows vollzogen.

Nun habe ich von einem Kunden eine .dbf-Datei unbekannter Herkunft bekommen, die in einem neuen Projekt weiterverwendet werden soll. Die dazugehörenden Indexdateien tragen die Endung .ntx, doch werden in "dbu" die Datumsfelder nicht korrekt angezeigt. Auch in Foxpro 6 steht dort nur Müll.

Gibt es sowas wie ein Tool zum identifizieren von .dbf-Dateien? Oder eine einfache Methode um das händisch zu machen?

Merci

dirk

[Wolfgang Ciriack]

Kannst ja mal die dbf in xls umbenennen und mit Excel aufmachen, was da so als Datum angezeigt wird.

[brandelh]

Hi,

das DATUM ist in der DBF eindeutig festgelegt. Intern wird schon immer YYYYMMTT gespeichert.

Was zeigt denn DBU an ?

Man kann anhand der ersten Bytes der DBF den TYP ermitteln, in der Wissensdatenbank habe ich dafür eine Funktion mit einer Klasse veröffentlicht.
Allerdings beziehen sich diese Unterschiede auf die Unterscheidung FOXPRO, DBFNTX, DBFCDX - also Memodateien, Indexdateien und gültige Feldtypen.
Datumsfelder sind in allen gleich.

Wenn du einen HEX-Editor hast (ich nutze dazu meinen MED) einfach mal die DBF damit öffnen und nachsehen was wirklich drinn steht.
Notfalls geht auch rechter Mausklick auf die DBF und öffnen mit Editor **** NICHT SPEICHERN ****.

[diwa]

In Excel wird das gleiche angezeigt, wie in DBU.

Es handelt sich um 3 Zeichen.
Z.B. x2F x02 x55 oder x2F x1C x5A

Ich sollte vielleicht mal schauen, ob ich für einige Datensätze die dahinter steckenden Datumswerte bekommen kann...

Das löst aber nicht das Problem, mit welchem Programm diese Datenbanken erstellt werden.

Ciao

dirk

[diwa]

OK - ich hätte mir vielleicht mal die Struktur anschauen sollen.
Die Datumswerte werden in Felder vom Typ CHARACTER der Länge 3 abgelegt...
Da hat also wer was gebastelt

Merci

Dirk

[Martin Altmann]

Moin Dirk,
vielleicht hilft Dir der Thread aus der Alaska-Newsgroup da weiter? Da geht es darum, mittels einer Funktion ein Datum in ein 3-Zeichen-Feld zu quetschen:
http://news.alaska-software.com/readmes ... .bugreport

Viele Grüße,
Martin

[diwa]

Nein, NTOC bzw. CTON helfen nicht weiter.
Ich denke, da ist irgendwas auf Zeichenebene kodiert - stehe aber wie der Ochs vorm Berg

Hier mal ein paar Beispiele:

Code: Alles auswählen

08.01.1965  - 2E133E - 001011100001001100111110 - 3019582
26.03.1965  - 2E1406 - 001011100001010000000110 - 3019782
15.02.1970  - 2E2260 - 001011100010001001100000 - 3023456
25.03.1970  - 2E230A - 001011100010001100001010 - 3023626
24.06.1970  - 2E2369 - 001011100010001101101001 - 3023721

Ciao

dirk

[Koverhage]

eventuell BCD ?

[Tom]

Das schaut aus, als würde es sich um einen Offset handeln, in dem mehr als nur das Datum steckt.

[diwa]

Ja - und die Abstände zwischen den einzelnen Werten sind auch nicht stimmig wenn man den reinen Zahlenwert betrachtet.

Zwischen dem 25.3. und dem 24.6. sind 91 Tage, der Wert unterscheidet sich aber um 95.
Zwischen dem 15.2. und dem 25.3. sind 38 Tage, der Unterschied beträgt aber 170.

Deshalb meine Vermutung mit der Zeichenkodierung.
Im ersten Fall sind es 2 Zeichen Unterschied, beim zweiten 3.

Ciao

dirk

[AUGE_OHR]

Hier mal ein paar Beispiele:

Code: Alles auswählen

08.01.1965  - 2E133E - 001011100001001100111110 - 3019582
26.03.1965  - 2E1406 - 001011100001010000000110 - 3019782
15.02.1970  - 2E2260 - 001011100010001001100000 - 3023456
25.03.1970  - 2E230A - 001011100010001100001010 - 3023626
24.06.1970  - 2E2369 - 001011100010001101101001 - 3023721

da es sich wohl um eine "alte" Datei handelt würde ich mal bei http://www.the-oasis.net suchen was du da an "Datum" Funktionen findest.
auch in der http://groups.google.com/group/comp.lang.clipper/topics war vor einiger Zeit ein solcher Thread wegen "UnpackDate() Clipper 5.01"

[diwa]

da es sich wohl um eine "alte" Datei handelt würde ich mal bei http://www.the-oasis.net suchen was du da an "Datum" Funktionen findest.

Die Suchfunktion auf der Seite ist leider defekt - und beim manuellen Suchen ist mir nichts aufgefallen, was hilfreich wäre...

auch in der http://groups.google.com/group/comp.lang.clipper/topics war vor einiger Zeit ein solcher Thread wegen "UnpackDate() Clipper 5.01"[/quote]

UnpackDate (bzw. eine Funktion, die so ähnlich funktioniert) hatte ich schon mal im Auge.
Leider kommen dabei aber keine brauchbaren Ergebnisse raus...

Ich hab' auch mal in die Index-Dateien geschaut. Dort werden die Datumsfelder "einfach so" in den Index aufgenommen, ohne vorher dekodiert zu werden...

Immer noch ratlos

Dirk

[brandelh]

Hi,

wenn die Lösung nicht offensichtlich ist, kannst du nur versuchen über den Eigentümer der
DBF soviel Infos wie möglich zu bekommen.
Wenn du Glück hast, gibt es Quellcode oder eine "Übersetzung" ...

[AUGE_OHR]

da es sich wohl um eine "alte" Datei handelt würde ich mal bei http://www.the-oasis.net suchen was du da an "Datum" Funktionen findest.

Die Suchfunktion auf der Seite ist leider defekt - und beim manuellen Suchen ist mir nichts aufgefallen, was hilfreich wäre...

Expand, SIX3 oder Nanforum haben Datums Funktionen

auch in der http://groups.google.com/group/comp.lang.clipper/topics war vor einiger Zeit ein solcher Thread wegen "UnpackDate() Clipper 5.01"

UnpackDate (bzw. eine Funktion, die so ähnlich funktioniert) hatte ich schon mal im Auge.
Leider kommen dabei aber keine brauchbaren Ergebnisse raus...

hast du den kompletten Thread "gelesen" ?

[Ewald]

Hallo Dirk,
ist dieses Problem noch ungelöst ? Ich habe unlängst mal Daten aus einer uralten Nixdorf-Anlage übersetzt ...
Würde ich mal mitknobeln, nur bin ich etwas verwirrt. Was steht denn in der DBF in dem 3 stelligen Feld ?
Zitat
Es handelt sich um 3 Zeichen.
Z.B. x2F x02 x55 oder x2F x1C x5A
Heißt das, das in dem Feld der DBF z.B x2F steht und im nächsten x02 und im nächsten x55 ?

Und woher kommen diese Daten ?

Code: Alles auswählen

08.01.1965  - 2E133E - 001011100001001100111110 - 3019582
26.03.1965  - 2E1406 - 001011100001010000000110 - 3019782
15.02.1970  - 2E2260 - 001011100010001001100000 - 3023456
25.03.1970  - 2E230A - 001011100010001100001010 - 3023626
24.06.1970  - 2E2369 - 001011100010001101101001 - 3023721

Ist das ein Auszug aus der DBF oder hast du das Datum dazu irgendwie identifiziert ?
Ich könnte evtl. weiterkommen, wenn ich nur den 3stelligen String aus der DBF hätte und dazu das von
dir manuell gefundene Datum.
Gruß
Ewald

[diwa]

ist dieses Problem noch ungelöst ?

Ja - und nachdem ich an anderer Stelle (http://www.office-loesung.de/) einen Forumsbeitrag gefunden hatte, der sich um das gleich Problem drehte - und der auch ergebnislos eingestellt wurde, hab ich das Problem erst mal beiseite geschoben

würde ich mal mitknobeln, nur bin ich etwas verwirrt. Was steht denn in der DBF in dem 3 stelligen Feld ?
Zitat
Es handelt sich um 3 Zeichen.
Z.B. x2F x02 x55 oder x2F x1C x5A
Heißt das, das in dem Feld der DBF z.B x2F steht und im nächsten x02 und im nächsten x55 ?

Das Feld ist vom Typ CHAR und 3 Zeichen lang.

obige Zahlen sind die HEX entsprechung der 3 Zeichen - da es öfters vorkommt, dass eines oder mehrere dieser Zeichen nicht vernünftig darstellbar sind.

Und woher kommen diese Daten ?

Code: Alles auswählen

08.01.1965  - 2E133E - 001011100001001100111110 - 3019582
26.03.1965  - 2E1406 - 001011100001010000000110 - 3019782
15.02.1970  - 2E2260 - 001011100010001001100000 - 3023456
25.03.1970  - 2E230A - 001011100010001100001010 - 3023626
24.06.1970  - 2E2369 - 001011100010001101101001 - 3023721

Ist das ein Auszug aus der DBF oder hast du das Datum dazu irgendwie identifiziert ?
Ich könnte evtl. weiterkommen, wenn ich nur den 3stelligen String aus der DBF hätte und dazu das von
dir manuell gefundene Datum.

Das sind identifizierte Daten (Mehrzahl von Datum) mit ihrer Entsprechung in HEX, BIN und DEZ.
Also der 8.1.1965 wird durch die 3 Zeichen CHR(x2E), chr(x13) und chr(x3E) in der Datenbank gespeichert.
Ich habe ausprobiert, ob da vielleicht Bits geshiftet werden oder man sonst irgendwas an den Entsprechungen sieht...


Unter dem oben angegebenen Link findet sich eine große Datei mit über 6000 Beispielen.
Allerdings sind dort einige Dinge recht eigenartig - so gibt es Daten, die doppelt vorkommen, aber unterschiedliche 3Zeichen-Darstellung aufweisen. Daher bin ich mir nicht so sicher, was die Verlässlichkeit dieser Daten angeht.

Meine Daten sind aber korrekt

Ciao

dirk

[Martin Altmann]

Moin Dirk,
na zumindest die Darstellung Deiner Hexzeichen und der Binärzeichen ist doch identisch!
Du hast 24 Binärzahlen = 3 Byte.
Jeweils 8 Ziffern entsprechen einer Deiner Hexwerte (die linken acht dem ersten Hexwert, die mittleren acht dem zweiten Hexwert und die rechten acht dem dritten Hexwert).
Die Dualzahl umgerechnet in Dezimal ist dann der Wert rechts in Deiner Auflistung (der Dezimalwert).
Ich hätte jetzt gedacht:
Man braucht 5 Bit für die Tage (mehr als 31 geht nicht!) und 4 Bit für den Monat (3 wären ja maximal eine 7 und damit zu wenig). Wären 9 Bit und somit blieben dann noch 15 übrig für das Jahr also maximal bis ins Jahr 32767. Zu viel!
Nehmen wir jedoch nur 13, hätten wir maximal das Jahr 8191.
Ergo:
Die rechten 13 Ziffern sind das Jahr, die vier davor der Monat und die ersten 7 (links mit Null aufgefüllt) der Tag.
Haut aber leider trotzdem nicht hin.
Schade.

Viele Grüße,
Martin

[diwa]

na zumindest die Darstellung Deiner Hexzeichen und der Binärzeichen ist doch identisch!
Du hast 24 Binärzahlen = 3 Byte.
Jeweils 8 Ziffern entsprechen einer Deiner Hexwerte (die linken acht dem ersten Hexwert, die mittleren acht dem zweiten Hexwert und die rechten acht dem dritten Hexwert).
Die Dualzahl umgerechnet in Dezimal ist dann der Wert rechts in Deiner Auflistung (der Dezimalwert).

ich weiß - das habe ich auch mittels Excel-Skript ausgerechnet
Original hatte ich nur die Hex-Zahlen aus dem Datei-Editor...

Ich hätte jetzt gedacht:
Man braucht 5 Bit für die Tage (mehr als 31 geht nicht!) und 4 Bit für den Monat (3 wären ja maximal eine 7 und damit zu wenig). Wären 9 Bit und somit blieben dann noch 15 übrig für das Jahr also maximal bis ins Jahr 32767. Zu viel!
Nehmen wir jedoch nur 13, hätten wir maximal das Jahr 8191.
Ergo:
Die rechten 13 Ziffern sind das Jahr, die vier davor der Monat und die ersten 7 (links mit Null aufgefüllt) der Tag.
Haut aber leider trotzdem nicht hin.
Schade.

JA, es gibt da auch noch andere Spielarten, wie man ein Datum in 3 Bytes "verpacken" kann - aber bisher habe ich die passende noch nicht gefunden...

Ciao

dirk

[Koverhage]

Ich habe erst gedacht Tage seit ####
Klappt aber auch nicht.
Hat der Kunde den die Anwendung noch, mit der die Datei
bearbeitet wird ? Dann könnte man die doch debuggen
bzw. mit Valkyrie (wenn es eine Clipper Anwendung ist)
oder ähnlichem schauen was da abläuft.