Hallo Gemeinde,
ich konnte über die üblichen Suchmaschinen leider keine Informationen zum entsprechenden Thema finden.
Folgendes ist das SQL-Statement, mit dem die Datei erzeugt wird:
In OpenOffice stelle ich entsprechend Als Spaltentrenner "," und als Texttrenner ein einfaches Anführungszeichen ein.
Wenn ich das Ganze via SQL-Befehl wieder in eine Datenbank einspielen will, klappt das auch wunderbar. Die Daten werden richtig eingelesen.
In OpenOffice werden dagegen die Zeilen teilweise zerschossen.
In den Datensätzen der CSV-Datei kommen selbst auch Daten mit einfachen, wie auch doppelten Anführungszeichen vor.
Ich frage mich jetzt natürlich, ob die Datei falsch exportiert worden ist.
In die Datenbank wird sie schließlich mit der selben Datenbank-Software (MySQL) wieder eingespielt. MySQL könnte diesen Bug also selbst gefixed haben, ohne das es zu Inkompatibilitäten kommt.
Das das aber auf lange Sicht so geblieben wäre, kann ich mir nicht denken.
Die nächste Möglichkeit bestünde darin, dass OpenOffice hier die Daten falsch einliest und der Fehler bei Open Office liegt.
Das Problem entsteht genau dort, wo das letzte Zeichen eines Feldinhaltes ein einfaches Anführungszeichen ist. Ich vermute, dass sich dadurch beim Parsen irgendetwas verschiebt und erst dann wieder einrenkt, wenn die selbe Situation bei einem anderen Datensatz auftritt. Zumindest geht das aus meinen Beobachtungen hervor. Woher sollte OpenOffice auch wissen, dass das betroffene Zeichen noch zum Feldinhalt gehört?
Irgendeine Idee, wie man das via SQL lösen könnte?
ESCAPED BY hat bisher keine Wirkung gezeigt und möchte ich im Moment auch nicht verwenden, weil ich nicht weiß, wie ich es in SuperCSV einbringen soll.
Danke für jeden Ansatz!
Beste Grüße
EDIT: Zur Situation:
Die CSV-Datei wird aus der Datenbank exportiert und soll anschließend von einem Programm abgeholt und eingelesen werden.
Falls Dritte aber interessiert, wie die fertige CSV aussieht, warum auch immer, soll die Darstellung in Programmen wie OO korrekt laufen.
Da die Weiterverarbeitung zum ersten mal für mich mit SuperCSV erfolgt, will ich im Voraus sicherstellen, dass der Export auch korrekt funktioniert.
Ich will dadurch vermeiden, Fehler in SuperCSV-Code bzw. meiner Anwendung zu suchen, wenn diese Fehler von ganz anderen Stellen zu verantworten sind.
ich konnte über die üblichen Suchmaschinen leider keine Informationen zum entsprechenden Thema finden.
Folgendes ist das SQL-Statement, mit dem die Datei erzeugt wird:
SQL:
SELECT...
INTO OUTFILE "'../output"
FIELDS TERMINATED BY "," ENCLOSED BY "'"
LINES TERMINATED BY "\n"';Wenn ich das Ganze via SQL-Befehl wieder in eine Datenbank einspielen will, klappt das auch wunderbar. Die Daten werden richtig eingelesen.
In OpenOffice werden dagegen die Zeilen teilweise zerschossen.
In den Datensätzen der CSV-Datei kommen selbst auch Daten mit einfachen, wie auch doppelten Anführungszeichen vor.
Ich frage mich jetzt natürlich, ob die Datei falsch exportiert worden ist.
In die Datenbank wird sie schließlich mit der selben Datenbank-Software (MySQL) wieder eingespielt. MySQL könnte diesen Bug also selbst gefixed haben, ohne das es zu Inkompatibilitäten kommt.
Das das aber auf lange Sicht so geblieben wäre, kann ich mir nicht denken.
Die nächste Möglichkeit bestünde darin, dass OpenOffice hier die Daten falsch einliest und der Fehler bei Open Office liegt.
Das Problem entsteht genau dort, wo das letzte Zeichen eines Feldinhaltes ein einfaches Anführungszeichen ist. Ich vermute, dass sich dadurch beim Parsen irgendetwas verschiebt und erst dann wieder einrenkt, wenn die selbe Situation bei einem anderen Datensatz auftritt. Zumindest geht das aus meinen Beobachtungen hervor. Woher sollte OpenOffice auch wissen, dass das betroffene Zeichen noch zum Feldinhalt gehört?
Irgendeine Idee, wie man das via SQL lösen könnte?
ESCAPED BY hat bisher keine Wirkung gezeigt und möchte ich im Moment auch nicht verwenden, weil ich nicht weiß, wie ich es in SuperCSV einbringen soll.
Danke für jeden Ansatz!
Beste Grüße
EDIT: Zur Situation:
Die CSV-Datei wird aus der Datenbank exportiert und soll anschließend von einem Programm abgeholt und eingelesen werden.
Falls Dritte aber interessiert, wie die fertige CSV aussieht, warum auch immer, soll die Darstellung in Programmen wie OO korrekt laufen.
Da die Weiterverarbeitung zum ersten mal für mich mit SuperCSV erfolgt, will ich im Voraus sicherstellen, dass der Export auch korrekt funktioniert.
Ich will dadurch vermeiden, Fehler in SuperCSV-Code bzw. meiner Anwendung zu suchen, wenn diese Fehler von ganz anderen Stellen zu verantworten sind.
Zuletzt bearbeitet:
