DBFNTX nach FOXCDX [Erledigt]

[Jan]

Hallo,

ich will DBFNTX nach FOXCDX konvertieren. Ich habe also:

• die dbesys angepasst, damit dort beide DBE geladen werden. Nach den FOXCDX-Einstellungen (Lifetime, Lockmode) den Eintrag "DbeInfo(COMPONENT_DATA, DBFDBE_ANSI, .T.) " hinzugefügt. Standard-DBE bleibt DBFNTX
• alle dbf im Verzeichnis per Directory() eingelesen
• jeden Eintrag per DbExport() nach "dummy.dbf" geschoben, mit dem achten Parameter "FOXCDX"
• die dummy.dbf nach dem Eintrag im directory-Array umbenannt

Soweit klappt das auch alles. Aber: Ich bin mir nicht sicher, ob der jetzt wirklich nach ANSI gewandelt hat. In den Programmen sieht das alles korrekt aus, aber Xbase++ kann ja auch intern alles automatisch wandeln. Schaue ich mir die dbf in einem DBF-Viewer an, sind alle Umlaute verhackstückelt.

Was mache ich da falsch?

Jan

[Tom]

Beim Erzeugen von FOXCDX-Tabellen entscheidet der Schalter SET CHARSET, ob die Tabellen in ANSI oder OEM entstehen. Du musst also auf jeden Fall im Moment der Konvertierung SET CHARSET TO ANSI gesetzt haben, sonst sind die Tabellen in OEM. DBFNTX ist immer in OEM. Für die ist der Schalter also unerheblich.

[Jan]

Hallo Tom,

aaahhhh! OK, danke für den Hinweis. Ich schau mal morgen beim Kunden in den Code, ob das da drin steht. Ich denke aber mal nicht. Ich dachte auch, das die DBE-Einstellung da reichen würde.

Jan

[Jan]

Hallo Tom,

in der Routine zum konvertieren der dbf habe ich gleich vorneweg ein SET CHARSET TO ANSI drin stehen. Das kann es also nicht sein.

Welchen Weg habe ich eigentlich zu erkennen, ob eine dbf ANSI oder ASCII ist?

Jan

[Tom]

Welchen Weg habe ich eigentlich zu erkennen, ob eine dbf ANSI oder ASCII ist?

DBF im Editor/Notepad öffnen. Nach einem Text z.B. mit Umlauten suchen. Wenn die Umlaute je nach (automatischer) Auswahl im Menü "Codierung" richtig angezeigt werden, stimmt der Zeichensatz: Werden sie mit "ASCII/DOS" dargestellt, ist es OEM, werden sie mit "ANSI/lokale Codeseite" dargestellt, ist es ANSI.

[Jan]

Tom,

wenn das denn man so einfach wäre. Im Notepad bzw. Editor kann ich nirgends die Codierung abfragen. Ansonsten hätte ich das ja schon längst so gemacht.

Jan

[Tom]

Uh, stimmt, das ist ja überhaupt nicht Notepad, sondern der "Lister" aus dem "Total Commander".

www.ghisler.com

Tabelle markieren und <F3> drücken.

[brandelh]

du kannst jeden HEX-Editor nehmen. Ich nehme meinen MED, aber ich meine auch notepad+ hätte das getan.

[Tom]

Geht auch z.B. mit MultiEdit. Je nach gewählter Codierung sieht man Umlaute oder eben nicht.

[Jan]

Da es offensichtlich irgendein grundsätzliches Problem gibt, und das Programm aus unerfindlichen Gründen bei manchen dbf reproduzierbar abstürzte, habe ich das jetzt umgeschrieben. DbExport() raus, und alles manuell durchziehen. Jetzt stimmt Zeichensatz, und es gibt auch keine Abstürze mehr.

Das erinnert mich daran, das ich schon früher mal mit DbExport() gekämpft hatte und das damals auch fluchend rausgeschmissen habe.

Jan

[brandelh]

Ich könnte mir Vorstellen, dass bei DBExport() aus Sicherheitsgründen kein Zeichensatzwechsel stattfindet.

[Tom]

Mit dem neunten Parameter von DbExport() kann man Infos für die DBE vorgeben (COMPONENT_DATA), aber offensichtlich erbt die Tabelle in dieser Situation tatsächlich den Zeichensatz (hab's gerade ausprobiert). Also besser Tabelle erzeugen und Datensätze in einer Schleife übertragen - dann funktioniert die Abhängigkeit von SET CHARSET auch.

[Jan]

Tom,

ja, genau das mache ich jetzt auch. Und es funktioniert einwandfrei. Wie beschrieben hatte ich zusätzlich auch noch ein Absturzproblem. Aus irgendeinem Grund ließen sich manche dbf nicht erzeugen oder öffnen. Nachvollziehbar immer die gleichen. Von gut 50 dbf waren das ca. fünf. Mit meiner eigenen Schleife habe ich diese Probleme überhaupt nicht mehr.

Jan

[Manfred]

Ich klinke mich mal hier rein mit meiner Frage des gleichen Themas.

Ich muß auch von DBFNTX auf FOXCDX umstellen, habe aber das problem, dass es flexibel gehalten werden muß. Das bedeutet, die Umstellung kann einmalig sein, aber auch mehrmalig, da es passieren kann, das Datensicherungen zurückgespielt werden, die DBFNTX noch haben. Über den Sinn und Zweck möchte ich hier aber auf keinen Fall diskutieren, es ist so und es läßt sich nicht ändern.

Das Problem das sich mir nun stellt ist folgendes:

Wenn ich eine DBF mit FOXCDX öffne, dann prüfe ich derzeit nach ob es fehlerfrei klappte. Wenn ja, dann alles ok, wenn nein, dann prüfe ich, ob es evtl. mit dem DBFNTX Treiber geht. Wenn der DBFNTX Treiber noch in der DBF ist, dann wird jetzt umgewandelt. Dieses Konzept scheint aber nur zu greifen, wenn es eine DBT Datei für die DBF gibt, die in eine FPT konvertiert werden muß. Wenn ich eine DBF habe, die keine DBT Datei hat, aber noch unter DBFNTX erzeugt wurde, dann wird diese mit dem FOXCDX Treiber problemlos geöffnet. Lt. Anleitung scheint der FOXCDX Treiber auch eine DBFNTX DBF öffnen zu können. Aber ob das später mal Probleme geben kann, das würde ich doch vorher wissen. Ansonsten wäre noch interessant, welche n Weg man noch beschreiten kann, außer zuerst mit FOXCDX und dann probeweise mit DBFNTX (ujnd dann zu konvertieren) zu öffnen wenn es Probleme gibt. Hat jemand einen Tipp?

[Jan]

Hallo Manfred,

man kann den Dateiheader auslesen. Jede dbf-Version hat seinen eigenen Eintrag da drin. Z. B. http://msdn.microsoft.com/en-us/library ... 71%29.aspx

Jan

[brandelh]

Die Indexdateien sind kein Problem, die kann man einfach neu aufbauen.
Wenn du aber neue Datenfelder oder Memodateien hast, muss das schief gehen.

Geht es dir darum zu erkennen, welcher Treiber nötig ist ?

Dazu habe ich in der Wissensbasis eine Klasse veröffentlicht, FOXDBE Dateien haben nämlich eine andere Typkennung als DBFNTX Dateien.

HB_DBF_INFO_CLASS - Infos über eine DBF erfahren: DBE etc.
http://www.xbaseforum.de/viewtopic.php? ... 13&p=86451

Fremde DBF öffnen, mit DBFNTX, DBFCDX oder FOXCDX ?
http://www.xbaseforum.de/viewtopic.php?f=16&t=1774

[Manfred]

Hubert,

ich glaube Du verstehst falsch. Ich muß für unabsehbare Zeit die Möglichkeit haben, DBFNTX zu öffnen und dann in FOXCDX zu konvertieren. Das ist nicht das Problem. das Problem liegt darin, dass der FOXCDX Treiber auch DBFNTX Dateien öffnet ohne zu murren. Somit kann ich erstmal nicht erkennen, welchen Ursprung der Treiber der DBF hat. Außer es liegt eine MEMO Datei vor. Dann knallt es. Das kann ich aber abfangen und entsprechend reagieren. Wenn die Weiterverarbeitung so aber keim Problem darstellt, weil der FOXCDX Treiber auch ursprüngliche DBFNTX DBF verarbeiten kann, dann wäre alles gut. ist es aber so?

Die Idee von Jan ist evtl. nicht schlecht, aber was bekomme ich dann ausgelesen, wenn ich eine DBF erstmal kurz vorher mit FREAD() öffne und mir di ersten Bytes anschaue? Das entzieht sich im Moment meinem Verständnis. Das wäre nämlich auch eine elegante Lösung. Vorher nachsehen und dann direkt richtig reagieren.

[Sören]

Hallo Manfred,

vielleicht hilft Dir ja diese Funktion weiter:

Code: Alles auswählen

// - Rueckgabe: entweder "DBF" oder "FOX" oder "" = unbekannt
// - cDBF muss den vollstaendigen Dateinamen inkl. Dir enthalten
// - Datei darf nicht exklusive geoeffnet sein
FUNCTION DBFType( cDBF )

  LOCAL cDBE := ""
  LOCAL nHandle, cBytes

  if (  nHandle := FOpen( cDBF, FO_READ )  )  !=  -1

    cBytes := Space( 1 )
    FSeek( nHandle, 0, FS_SET )  // auf Byte 0 gehen
    FRead( nHandle, @cBytes, 1 )  // 1 Byte einlesen
    FClose( nHandle )

    if cBytes $ Chr( 0x03 ) + Chr( 0x83 )  // dBase 3 ohne oder mit Memo
      cDBE := "DBF"
    elseif cBytes $ Chr( 0x30 ) + Chr( 0x31 ) + Chr( 0xF5 )  // Visual Foxpro ohne oder mit Memo oder Foxpro 2.6 mit Memo
      cDBE := "FOX"
    endif

  endif

RETURN cDBE

[Manfred]

Hi Sören,

das sieht genau richtig aus. habe mal wieder etwas geschlafen, wie das funktioniert. Für mich ist nur wichtig, ob NTX oder CDX. Memodatei ist wurscht, es wird dann sowieso konvertiert.

[brandelh]

Na Manfred,

du liest nur nicht was ich schreibe !
Jeder meiner Links führte zu einer Function / Klasse, die ganau über den HEADER der DBF feststellt, welcher TYP die DBF hat (dbase 3 bis ... => DBFNTX, VisualFoxPro => FOXCDX).
Anhand dieses Types kann man dann die zutreffende DBE wählen !
Um an den Typ zu kommen nutze ich intern auch FREAD()

[Manfred]

Doch,

aber Du hast wieder mal die eierlegende Wollmilchsau gebaut. Das war mir zuviel. Sörens Ding war genau richtig knapp und kurz. Aber trotzdem Dank an Dich.

[brandelh]

Für mich ist nur wichtig, ob NTX oder CDX. Memodatei ist wurscht, es wird dann sowieso konvertiert.

und das ist mal eben falsch
Die Fehlermeldung kommt, wenn du mit der DBFDBE eine Datei öffnen willst die FOXDBE benötigt (Memo, Feldtypen etc.).
Wenn die Daten-DBE stimmt, kannst du die Index-DBE deiner Wahl nutzen, aber auch z.B. DBFCDX !

[Manfred]

nee, nöppes,

ich öffne mit der FOXCDX eine DBFNTX DBF und das geht. Aber egal, lassen wir es gut sein, ich habe jetzt eine Lösung, die mich weiterbringt.

[Manfred]

Also die Abfrage des 1.Bytes auf die Engine klappt nicht.

Code: Alles auswählen

if cBytes $ Chr( 0x03 ) + Chr( 0x83 )  // dBase 3 ohne oder mit Memo
      cDBE := "DBF"
    elseif cBytes $ Chr( 0x30 ) + Chr( 0x31 ) + Chr( 0xF5 )  // Visual Foxpro ohne oder mit Memo oder Foxpro 2.6 mit Memo
      cDBE := "FOX"
    endif

wenn ich das so einbaue wird jedesmal Dbase3 angenommen auch wenn ich direkt vorher die DBF mit dem FOXCDX Treiber erzeugt habe. Irgendwas ist da wohl faul

[brandelh]

du könntest ja mal in meine völlig überzogene Funktion sehen

ist val(cByte) also immer 3 ?

PS: eine DBF OHNE MEMO und NUR MIT NORMALEN (alten Clipperfeldern) ist eine dBase3 DBF !
Eine bestehende dBase3 DBF kann mit jeder der beiden DBE (DBFDBE und FOXDBE) bearbeitet werden ... sonst gäbe es eine Fehlermeldung
Schließlich hat FoxPro selbst ja auch Standard dbase 3 DBFs geöffnet