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.