Unidac Umlaute nicht richtig angezeigt

[Alfredo]

Delphi 10.3.3; Unidac 8.1.2 Trial, *.dbf(Visual Foxpro 9.0)

Mit TTable(BDE) werden ä, ö und ü in einem TDBGrid richtig angezeigt.

Mit TUniConnection, TUniQuery und TDBFUniProvider leider nicht.

[hstreicher]

Bei mir mit IBDac musste ich in der Connection Komponente die Eigenschaft UseUnicode (oder so ähnlichm habe gerade kein Delphi greifbar) auf True setzten dann gings

hth Hannes

[Alfredo]

Trotz 'Use UniCode = True' im Connetionstring leider keine richtigen Umlaute.

Laut Hexeditor in der *.dbf ö=F6 und ü=FC.

[Bernhard Geyer]

Eher UseUnicode = False.

Das Foxpro-Datenbankformat kann(vermutlich) kein Unicode.
Oder sowas wie Charset einstellen.

[hans65]

Was sagen denn die Bytes 0 (file type) und 29 (Codepage mark) im Hexeditor?
Und erfolgt der Zugriff über den ODBC-Treiber oder über "DIRECT=true"?
Wenn die automatische Codepage-Zuordnung nicht klappt, kann mit "CodePage=dpWesternEuropeanANSI" der Zeichensatz vorgegeben werden.
Ich verwende hin und wieder Unidac mit Foxpro-dbf-Dateien, mit dem Zeichensatz habe ich aber eigentlich keine Probleme, eher mit der Geschwindigkeit.

Andreas

[Alfredo]

Hallo Andreas,

Byte 0 = 03
Byte 29 = 00

mit Direct = True sind die Umlaute richtig.
Der Start der Anwendung dauert dann jedoch sehr lange.

Gruß
Alfred

[hans65]

Hallo,
es ist also eine normale dBase-iii-Datei, ohne Zeichensatz-Kennzeichnung. Mit Direct=TRUE interpretiert Unidac die Daten und konvertiert in dieser Konstellation aus dbf-Format und Codepage (3/0) vermutlich garnichts. Bei Direct=FALSE erfolgt der Zugriff über einen ODBC-dBase-Treiber und der Treiber ist für die Konvertierung verantwortlich. Da dBase-iii noch aus DOS-Zeiten stammt, werden dann vermutlich alle Eingabedaten als ASCII interpretiert.
Leider kann ich "Direct=FALSE" bei mir nicht testen, da ich dann immer Fehlermeldungen erhalte. (Da ich es nicht benötige, ich greife ausschließlich per "Direct=true" zu, fehlt mir auch die Motivation da etwas zu ändern.)

Testen würde ich folgendes:

Code:

UniTable1.Connection.SpecificOptions.Values['CodePage']:='dpWesternEuropeanANSI';

Da in Deiner ursprünglichen Frage etwas von Foxpro stand, wäre eine zweite Möglichkeit, die betreffende dbf-Datei von Foxpro mit dem richtigen Zeichensatz markieren zu lassen. Eine entsprechende Nachfrage müsste ja kommen, wenn die Datei exklusiv in Foxpro geöffnet wird. Aber dann besteht wieder die Möglichkeit, dass der Odbc-Standard-dBase-Treiber das nicht kennt und du den Foxpro-Odbc-Treiber installieren musst.
Also vielleicht lieber erst mal kurz den obigen Befehl testen.

Andreas

[Alfredo]

Hallo Andreas,

der Befehl ändert an den Umlauten leider nichts.

Was ich herausgefunden habe ist, dass es bei dbase III noch kein belegtes Byte 29 gab
und Foxpro bei dbase III garnicht das Byte 29 prüft.

Erst ab dbase IV ist das Byte 29 als Codepage definiert.

Eine Änderung von Byte 0 mit dem HexEditor von 03 auf 30 endete im Chaos.

Ein Create einer neuen Table mit VisualFoxpro 9.0 und dbase plus 11 hat mir gezeigt, dass ich
bislang wohl mehr Glück als Verstand hatte.
Die neuen Tabellen können nur noch von dem Programm gelesen werden, dass es auch angelegt hat.

Meine Anwendung wurde noch mit Foxpro 2.0 programmiert und dann über 2.6 und VisualFoxpro
3.0, 6.0 und 9.0 hochgezogen. Das reine kopieren der Strukturen der Dateien hat mich wohl vor
den jetzt festgestellten Problemen verschont.

Mit dbgo und VPOLEDB(VFP 9.0) habe ich einen Zugriff hinbekommen.
Umlaute sind hier ok.
Formatierte Felder(z.B. 425 auf 425,00) haben jedoch Probleme beim editieren.

Gruß
Alfred