Problem mit .dbf als Austauschformat mit Excel

[Jumpy]

Hallo,

es gibt bei uns ein uraltes, die BDE benutzendes Tool, das es ermöglicht SQL-Statements gegen diverse Datenbanken zu schießen und die Ergebnismenge in eine .dbf-Datei zu speichern.

Dies sollte ohne großen Aufwand so umgebaut werden, dass es ohne BDE läuft und ich benutze nun TBDF zur Erzeugung der .dbf-Datei.

Ich hab nun das Problem, dass die Umlaute falsch ankommen, wenn ich die Datei in Excel 2007 wieder öffne. Schau ich mir die Datei im Texteditor an, oder importiere ich sie mal testweise in Access, kommen die Umlaute richtig rüber.
Ich bin fast geneigt, das als Excel-Problem abzutun und habe so ziemlich alle CodePage/LanguageID Varianten, die man in der TDBF-Klasse so angeben kann und die mir sinnvoll schienen ausprobiert - ohne Erfolg.

Hat irgendwer da vllt. noch einen Rat für mich?

[Bernhard Geyer]

Wenn du schon Umbaust dann schmeiss doch das DBF-Format auch weg und nimm entweder ein Txt/CSV-Format oder XLS.

Ein Teil der Probleme die man hat liegen nicht an der BDE sondern am Speicherformat DBF!

[Jumpy]

Hallo,

andere Formate konnte das Programm schon (csv, xls). Ich hab jetzt noch XML hinzugefügt (TDataSet.SaveToFile) und wollte das .dbf wieder ans Laufen kriegen.

Hintergrund ist, dass die Kollegen die das benutzen Gewohnheitstiere sind und die weiteren Daten nachher für irgendwelche Spielereien Analysen in Excel brauchen.

Kleine Datenmengen werden dann direkt per Excel-Automation in eine .xls Datei geschrieben. Das ist aber bei großen Datenmengen recht langsam, weswegen man dann immer den Umweg über .dbf benutzt hat, weil das dann schnell ging und es keine Probleme mit den Datentypen gab.

CSV hat beim Import das Problem, dass man schon mal Probleme mit Datums(?) hat oder das führende Nullen, bei z.B. Personalnummern, weggelassen werden. Das kann man zwar idR verhindern, wenn man den Importdialog/-assistenten mit ein bisschen Verstand durcharbeitet, aber am dem bisschen scheitert es manchmal. Und der Programmierer ist dann immer schuld.

----------------------

Edit:
Habe gerade mal einen Testdatensatz mit nur einem Feld mit einem "ö" drin exportiert.
Im Hex-Editor angeguckt, da ist das als "FC" drin was ja glaub ich ANSI ist?
Anschließend in Access importiert, wo das ja geht und von dort wieder in eine neue .dbf exportiert.
Diese kann nun Excel richtig einlesen, es kommt das "ö".
Dann hab ich mir das nochmal im Hex-Editor angeguckt und da ist jetzt das ö als "81" gespeichert.

Ist das vllt. ein Hinweis darauf was Excel erwartet? Ist die 81 auch ANSI, oder ASCII oder sonstwas? Ich bin immer von diesen Codierungen verwirrt.

[Dejan Vu]

Versuche, die Dateien direkt ins XLS(X)-Format zu schreiben.
Das geht über ADO recht flott (soweit ich weiß), mit DevExpress sehr sehr bequem (wenn auch teuer), mit Komponenten von Axolot-Data (XLSMini oder XLSReadWriteII) sehr schnell und mit anderen Komponenten (z.B. TMS Flexcel) auch.

Als Alternative für ein gängiges kleines DB-Format ginge auch Access, zumal die Jet-Engine eigentlich auf jedem Windows-PC installiert ist.

Such mal hier im Forum nach Möglichkeiten. Ich würde dieses schrottige DBF-'Format' nicht mehr verwenden, zumal das kein Standard ist (FoxPro erzeugt DBF)

[Jumpy]

Die genannten Komponenten kosten ja alle was und da wir das sonst nirgendwo brauchen würden (nach jetzigem Stand der Dinge) will man dafür keine Kohle locker machen. Generell tut sich unsere Firma schwer mit Komponenten kaufen, da wir zu klein sind und mit den Dingen, die bei Delphi dabei sind meist klar kommen.

Ich hab nun auf jeden Fall mal einen Excel-Export über ADO realisiert und das ist tatsächlich schneller, als die alte Exportfunktion, dafür schon mal schönen dank.

Das .dbf Problem hab ich nach einigem Nachdenken auch gelöst oder eher umgangen. Ich speichere mit US-Codepage. Dadruch werden z.B. im Texteditor die Umlaute nicht mehr richtig dargestellt.
Der Excel-Import aber kann die nun einlesen und Excel "interpretiert" die dann aber "deutsch" und stellt die Umlaute richtig dar.

Mag natürlich sein, dass das auf dem Rechner des nächsten Kollegen, der ein rein deutsches Windows oder Office hat (nicht das universal-alle-Sprachen-US-Englische), wieder ganz anders aussieht. Aber für's erste ist die Funktionalität wieder drin, und ein paar neue Exporterweiterungen sind noch hinzugekommen. Danke :thumb:

[p80286]

Zitat:

Zitat von Jumpy (Beitrag 1255168)

Kleine Datenmengen werden dann direkt per Excel-Automation in eine .xls Datei geschrieben. Das ist aber bei großen Datenmengen recht langsam,....

"Langsam" ist ja relativ, meiner Meinung nach sind 10-20k Datensätze noch vertretbar.

Zitat:

Zitat von Jumpy (Beitrag 1255168)

CSV hat beim Import das Problem, dass man schon mal Probleme mit Datums(?) hat oder das führende Nullen, bei z.B. Personalnummern, weggelassen werden. Das kann man zwar idR verhindern, wenn man den Importdialog/-assistenten mit ein bisschen Verstand durcharbeitet, aber am dem bisschen scheitert es manchmal. Und der Programmierer ist dann immer schuld.

Tröste Dich Du bist da nicht alleine.
Was Die Datumse angeht, nimm doch das ISO-Format (YYYY.MM.DD oder YYYYMMDD) damit hatte ich bisher noch keine Probleme.

Gruß
K-H

[Jumpy]

Zitat:

Zitat von p80286 (Beitrag 1255259)

Was Die Datumse angeht, nimm doch das ISO-Format (YYYY.MM.DD oder YYYYMMDD) damit hatte ich bisher noch keine Probleme.

Gute Anregung. Muss ich mal testen. Bisher "looped" der CSV-Export einfach durch alle Datensätze und in jedem Datensatz durch alle Felder und schreibt das mit Query.Field[i].AsString in eine Stringlist.

Das kann man ja aufbohren, das abhängig vom Datentyp des Feldes was gemacht wird.