Array in csv schreiben

[hirsch]

Ich dachte, dass es einfach ist den Ihnalt eines Array's in eine csv zu schreiben, denn umgekehrt ist es das.
Was ich habe:

Delphi-Quellcode:

  AssignFile(output1, Ordner+'A.csv');
  if FileExists('A.csv') then begin
    reWrite(output1,'A.csv');
  end else begin
    FileCreate(Ordner+'A.csv');
  end;
  Reset(output1);


  for i := 0 to laenge-1  do begin
    if trim(FeldZeile[i,2])<>'' then
      zeile:=FeldZeile[i,0]+';'+FeldZeile[i,1]+' '+FeldZeile[i,2]+';'+FeldZeile[i,3]+';'+FeldZeile[i,4]
    else
      zeile:=FeldZeile[i,0]+';'+FeldZeile[i,1]+';'+FeldZeile[i,3]+';'+FeldZeile[i,4];
    append(output1);
    WriteLn(output1,Zeile);
  end;
  CloseFile(output1);
  Setlength(FeldZeile,0,0)

Das Seltsame daran ist, dass es auf dem Entwickler-PC funktioniert, aber dort auf dem Fileserver, wofür ich das gemacht habe, bekomme ich immer einen E/A-Fehler 32.
Der Programmbenutzer hat an dieser Stelle volles schreib.- und änderungsRechte.
Kann mir da jemand bitte helfen?

[baumina]

rewrite : Erstellt eine neue Datei und öffnet sie anschließend.
reset : Öffnet eine vorhandene Datei.

Also:

Delphi-Quellcode:

if FileExists(Ordner + 'A.csv') then begin
     Reset(output1);
   end else begin
     reWrite(output1);
   end;

[Zoot]

Ich würde als erstes mal aufräumen, ob "Ordner" nun zum Dateinamen gehört oder nicht, das wechselt derzeit in jeder Zeile.

[hirsch]

Ok, klingt logisch, DANKE.

Ich habe die IF gelöscht, dafür nur noch

Delphi-Quellcode:

reWrite(output1,Ordner+'A.csv');

Soll ja auch so sein, immer überschreiben...

[Sir Rufo]

Wenn du eine CSV nach RFC 4180 erzeugen möchtest, dann packe für jede Zeile alle Felder in eine TStringList und schreibe dann den TStringList.DelimitedText als resultierende Zeile. Die Stringlist kümmert sich dann auch um das korrekte Setzen des TStrings.QuoteChar und TStrings.Delimiter und du brauchst dir keinen Kopf machen.

Umgekehrt funktioniert das leider nur unter der Bedingung, wenn kein Feld einen Zeilenumbruch beinhalted ;)

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1283487)

Wenn du eine CSV nach RFC 4180 erzeugen möchtest, dann packe für jede Zeile alle Felder in eine TStringList und schreibe dann den TStringList.DelimitedText als resultierende Zeile. Die Stringlist kümmert sich dann auch um das korrekte Setzen des TStrings.QuoteChar und TStrings.Delimiter und du brauchst dir keinen Kopf machen.

Du meinst doch sicher TStringList.CommaText, oder?

[Sir Rufo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1283496)

Zitat:

Zitat von Sir Rufo (Beitrag 1283487)

Wenn du eine CSV nach RFC 4180 erzeugen möchtest, dann packe für jede Zeile alle Felder in eine TStringList und schreibe dann den TStringList.DelimitedText als resultierende Zeile. Die Stringlist kümmert sich dann auch um das korrekte Setzen des TStrings.QuoteChar und TStrings.Delimiter und du brauchst dir keinen Kopf machen.

Du meinst doch sicher TStringList.CommaText, oder?

Sicher nicht, denn hier wird das

Delphi-Quellcode:

;

als Trennzeichen benötigt

[Blup]

Nicht vergessen TStrings.StrictDelimiter auf True zu setzen.

[Sir Rufo]

Zitat:

Zitat von Blup (Beitrag 1283503)

Nicht vergessen TStrings.StrictDelimiter auf True zu setzen.

Ist aber auch nur für den anderen Weg (einlesen) wichtig und der ist, wie schon gesagt, eh limitiert und darum sollte man das Einlesen anders machen.

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1283498)

Sicher nicht, denn hier wird das

Delphi-Quellcode:

;

als Trennzeichen benötigt

RFC 4180 beschreibt doch COMMA (%x2C) als Trennzeichen zwischen den Feldern, oder?

[Sir Rufo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1283507)

Zitat:

Zitat von Sir Rufo (Beitrag 1283498)

Sicher nicht, denn hier wird das

Delphi-Quellcode:

;

als Trennzeichen benötigt

RFC 4180 beschreibt doch COMMA (%x2C) als Trennzeichen zwischen den Feldern, oder?

Das wichtigste an der RFC4180 wird fast immer übersehen

• Quoten beim Delimiter, QuoteChar oder Zeilenende-Zeichen im Feld

Das Trennzeichen ist da eher nebensächlich, es muss nur eindeutig und durchgängig sein (so wie QuoteChar).
Auch wenn eine CSV irgendwie als CommaSeparatedValues zu verstehen ist, erzeugt der TE Dateien mit einem Semikolon. Ist dass dann SSV?

Da CSV eh nur ein Quasi-Standard ohne gültige Definition (RFC 4180 ist quasi ein Vorchlag) kann ich auch behaupten es bedeutet customCharacterSeparatedValues :mrgreen:

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1283510)

Da CSV eh nur ein Quasi-Standard ohne gültige Definition (RFC 4180 ist quasi ein Vorchlag) kann ich auch behaupten es bedeutet customCharacterSeparatedValues :mrgreen:

Auch wenn es eigentlich eindeutig ist (custom), noch mal der Hinweis, je nach Spracheinstellung wählt z.B. Excel mal das Komma, mal das Semikolon als Feldtrenner. Darum vor dem Einlesen, sich immer vergewissern, welche Zeichen genutzt werden. Und falls man eine CSV-Datei versenden will, sich vielleicht vergewissern, daß der Empfänger damit auch umgehen kann.

Gruß
K-H

[Sir Rufo]

Die Wikipedia spricht auch von Character-Separated-Values und eben dass es nicht zwingend ein Komma sein muss.

Ja, es macht sich immer gut, vor einer Kommunikation sich auf einen Sprach-Kontext zu einigen, wie immer der auch aussieht.

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1283579)

je nach Spracheinstellung wählt z.B. Excel mal das Komma, mal das Semikolon als Feldtrenner.

Genauergesagt: Den ListSeparator. Der steht dort zwar drin, ist aber frei wählbar.

Deshalb ist CSV als Datenaustauschformat auch denkbar ungeeignet.

[Blup]

Zitat:

Zitat von Dejan Vu (Beitrag 1283616)

Deshalb ist CSV als Datenaustauschformat auch denkbar ungeeignet.

Ist die Struktur als auch der Inhalt einer CSV-Datei vorher sorgfälltig dokumentiert und danach umgesetzt worden, gibt es in der Praxis eigentlich kaum Probleme.

Mit Exceldateien ist Ärger eher die Regel als die Ausnahme.
- unterschiedlichen Dateiformaten
- OLE-Funktionen die von der Excelversionen abhängig, entgegen der Dokumentation unterschiedlich falsch funktionieren
- Komponenten in Fremdprogrammen die Exceldateien nur lesen können, wenn ein ganz bestimmtes Zellformat verwendet wurde (bei dem einen alles als Text formatiert, der nächste nur ohne Format)

[Dejan Vu]

Zitat:

Zitat von Blup (Beitrag 1283632)

Zitat:

Zitat von Dejan Vu (Beitrag 1283616)

Deshalb ist CSV als Datenaustauschformat auch denkbar ungeeignet.

Ist die Struktur als auch der Inhalt einer CSV-Datei vorher sorgfälltig dokumentiert und danach umgesetzt worden, gibt es in der Praxis eigentlich kaum Probleme.

Ich hätte dazuschreiben müssen: 'International'... "CSV kannste knicken und in die Tonne treten", um es salopp auszudrücken. Zum Austausch von Formaten nimmt man XML und XSD, dann gibt es da gar keine Mißverständnisse mehr.

"Probleme" gibt es auch nicht, wenn ich selbst lese, was ich irgendwo hin schreibe, oder Binärformate nehme (natürlich gut dokumentiert). Aber wozu gibt es wohl Standards? Wenn ich von 'extern' irgendwelche Daten bekommen soll, bestehe ich persönlich auf XML + Schema. Dann validiere ich einkommende Daten gegen das Schema und wenn das passt, passt es. Anders herum validiere ich alles, was rausgeht und wenn das passt, bin ich aus dem Schneider.

PS: CSV ist solcher Müll, das selbst mein SSMS (SQL Management Studio), welches *CSV* exportieren kann, nicht mit EXCEL klar kommt. Beides auf der selben Maschine installiert. Beides von Microsoft. Gleicher Laden, andere Abteilung. Von wegen 'keine Probleme' :-)

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1283642)

CSV ist solcher Müll, das selbst mein SSMS (SQL Management Studio), welches *CSV* exportieren kann, nicht mit EXCEL klar kommt. Beides auf der selben Maschine installiert. Beides von Microsoft. Gleicher Laden, andere Abteilung. Von wegen 'keine Probleme' :-)

Dabei könnte es so einfach sein einen Dialog davorzuschalten, wo man zumindestens Delimiter und QuoteChar einstellen könnte. Von Zeilenende und Start bei Zeile x würden wir im ersten Step absehen, wir wollen niemanden überfordern, der schon Probleme mit dem Auseinanderhalten von Tablet und Desktop hat :mrgreen:

[Dejan Vu]

Eine Firma bekommt Daten von über 40 Zulieferern natürlich per CSV. Die Firma ist eine Quasibehörde und daher ist diese Vereinbarung taufrisch, aus dem Jahre 1976. Seit 10 Jahren wird erst an der Nachfolgespezifikation gearbeitet, also muss die derzeit gültige taufrische Spezifikation noch einige Jahre halten. Also CSV..

40 Zulieferer. Für jeden Zulieferer einen eigenen Dialog. Speichern der Einstellungen bringt etwas, aber nicht viel, weil die Daten manchmal auch per Dienstleister im Ausland (manuell) erfasst werden. Ja. Elektronisch erfasste Daten werden ausgedruckt, ins A.A.Ausland geschickt, dort eingetippt und dann per CSV an die Quasibehörde geschickt. Per FTP. Mal mit Komma, mal mit Semikolon. Oder als WORD-Datei. Willkürlich formatiert. Oder EXCEL. Mal so, mal so.

Aber manchmal wird -höhöhö- der Ausdruck der vormals elektronisch erfassten Daten auch direkt an die Quasibehörde geschickt. Also ca. 500kg Papier. Die werden dann von eigens eingestellten professionellen Abtippern eingegeben. Zweimal. Weil diese Quasibehörde gibt es zwei Mal. Mmf. Grmpfl.

Ich schweife ab. Ich bin nicht mehr bei dem Verein.

Gott.
Sei.
Dank.

Wo war ich? Ach ja. In der Klapsmühle.

Nee, also in einen Importfilter mal einen Eingabe/Konfigurationsdialog einzubauen. Das hat was. Merke ich mir. :cyclops:

[smallie]

Ich versuche mich kurz zu fassen, weil wir OT sind.

Zitat:

Zitat von Dejan Vu (Beitrag 1283668)

Eine Firma bekommt Daten von über 40 Zulieferern natürlich per CSV.

Das trifft auf uns auch zu. Manche Zulieferer liefern jeweils für vier oder fünf Kunden, so daß am Ende täglich locker hundert Pakete eintreffen, die aus mehreren Dateien bestehen.

Die größeren Datenlieferungen bringen es täglich leicht auf 100 MB. Da purzeln die Gigabytes.

So - jetzt stell dir vor, das seien alles XMLs. Wieviel overhead würde das bedeuten? Mir fehlt die Erfahrung das einzuschätzen - ich tippe auf das fünffache oder zehnfache Volumen. Bitte korrigieren, falls ich daneben liege. In jedem Falle ist das als Kostenfaktor wegen Speicherung und Sicherung nicht zu unterschätzen, zumindest in der Liga, in der wir spielen.

Es gibt noch einen zweiten Aspekt: csv-Dateien harmonieren gut mit relationalen Datenbanktabellen. Mit direct load sind die Daten im Nu in der Datenbank, wenn normalisierte Stammdaten in eigenen Tabellen vorgehalten werden müssen. Erst ein XML zu parsen, nur um es letztlich doch in relationale Tabellen zu stecken, wäre ein unsinniger Aufwand, oder?

Zitat:

Zitat von Dejan Vu (Beitrag 1283668)

40 Zulieferer. Für jeden Zulieferer einen eigenen Dialog. Speichern der Einstellungen bringt etwas, aber nicht viel, weil die Daten manchmal auch per Dienstleister im Ausland (manuell) erfasst werden. Ja. Elektronisch erfasste Daten werden ausgedruckt, ins A.A.Ausland geschickt, dort eingetippt und dann per CSV an die Quasibehörde geschickt. Per FTP. Mal mit Komma, mal mit Semikolon. Oder als WORD-Datei. Willkürlich formatiert. Oder EXCEL. Mal so, mal so.

Naja. Das ist kein Problem, das der csv-Datei angelastet werden kann. Hier hapert es an der Organisation. Andersherum gesagt: traust die Leuten, die kein wohlgeformtes csv zu Wege bringen zu, daß sie gültige XMLs liefern?

Zitat:

Zitat von Dejan Vu (Beitrag 1283668)

Aber manchmal wird -höhöhö- der Ausdruck der vormals elektronisch erfassten Daten auch direkt an die Quasibehörde geschickt. Also ca. 500kg Papier. Die werden dann von eigens eingestellten professionellen Abtippern eingegeben. Zweimal. Weil diese Quasibehörde gibt es zwei Mal. Mmf. Grmpfl.

Ich hab' mich schon mehrmals gefragt, warum es hier im Forum keinen daily-WTF-Thread gibt. :stupid: Das wäre ein schöner Startbeitrag.

Zitat:

Zitat von Dejan Vu (Beitrag 1283668)

Nee, also in einen Importfilter mal einen Eingabe/Konfigurationsdialog einzubauen. Das hat was. Merke ich mir. :cyclops:

So etwas baue ich gerade. Ich sollte das mal vorstellen. Zu einem bestimmten Ansatz käme mir Manöverkritik ganz gelegen, bevor ich das festzurre.

[Dejan Vu]

Overhead? Das ist doch vollkommen egal. (Validiertes) XML ist weltweit identisch. Du kannst kein wohlgeformtes und validiertes XML bekommen, was Dir plötzlich Probleme macht. Wohl aber eine vollkommen zerschurbelte CSV-Datei.
Speicherplatz? Zip das Zeugs.

Zitat:

Zitat von smallie (Beitrag 1283677)

Es gibt noch einen zweiten Aspekt: csv-Dateien harmonieren gut mit relationalen Datenbanktabellen. Mit direct load sind die Daten im Nu in der Datenbank

Genau, weil es ja nur ein Format gibt und einen Trenner...

Zitat:

Andersherum gesagt: traust die Leuten, die kein wohlgeformtes csv zu Wege bringen zu, daß sie gültige XMLs liefern?

Es gibt kein 'wohlgeformtes CSV'. Es gibt wohlgeformtes XML (was mir auch egal wäre) und es gibt validiertes XML (gegen ein Schema).

Wenn deine Zulieferer alle mitspielen und wissen, was sie tun, können sie auch proprietäres Binärformat schicken. Jetzt schicken sie ein proprietäres Text-Format, aber wenigstens spielen sie mit.

PS: XML in einen Server geht genauso schnell und das Aufdröseln in Tabellen auch. Sind halt ein paar Zeilen mehr. Einmalig.

Aber jedem das Seine. CSV hat jedenfalls imho in der professionellen Softwareentwicklung und im Datenaustausch, der etwas auf sich hält, nichts verloren. Das ist nicht abwertend, sondern in meinem Umfeld so.

[smallie]

Zitat:

Zitat von Dejan Vu (Beitrag 1283678)

Speicherplatz? Zip das Zeugs.

Falls unser Admin nicht ohnehin schon komprimierte Verzeichnisse nutzt, ist das eine gute Idee.

Zitat:

Zitat von Dejan Vu (Beitrag 1283678)

Zitat:

Zitat von smallie (Beitrag 1283677)

Es gibt noch einen zweiten Aspekt: csv-Dateien harmonieren gut mit relationalen Datenbanktabellen. Mit direct load sind die Daten im Nu in der Datenbank

Genau, weil es ja nur ein Format gibt und einen Trenner...

Zitat:

Andersherum gesagt: traust die Leuten, die kein wohlgeformtes csv zu Wege bringen zu, daß sie gültige XMLs liefern?

Es gibt kein 'wohlgeformtes CSV'. Es gibt wohlgeformtes XML (was mir auch egal wäre) und es gibt validiertes XML (gegen ein Schema).

Naja, wir haben tatsächlich einen Lieferanten, bei dem immer nach einem Feiertag das Trennzeichen für einen Tag wechselt. Wir sind jedesmal auf's neue erstaunt. :shock:

Weiter gibt es einige Kandidaten, die es nicht schaffen, Quotes und Delimiter richtig zu escapen. Die sich sogar auf mehrmalige Nachfrage weigern, es richtig zu machen.

Im Großen und Ganzen aber gibt es keine Zweifel wie ein korrektes csv aussehen muß.

Zitat:

Zitat von Dejan Vu (Beitrag 1283678)

Wenn deine Zulieferer alle mitspielen und wissen, was sie tun, können sie auch proprietäres Binärformat schicken. Jetzt schicken sie ein proprietäres Text-Format, aber wenigstens spielen sie mit.

Ich wäre der erste, der in unserem Laden ein Veto gegen ein Binärformat einlegt - und sicher nicht der einzige. Von Menschen lesbare Dateien sind im Sinne von "machs einfach" nicht zu schlagen. Gerade heute hatte ich einen Fall, da wurden Geldbeträge mit sechs Nachkommastellen importiert. Ein kurzer Blick in die Datei reichte aus, um zu sehen, daß die Nachkommastellen tatsächlich so geliefert wurden und nicht vom Importer aufgrund eines aberwitzigen Fehlers hinzugemogelt wurden.

Solch ein Binärformat wäre die Hölle für mich, ebenso wie für den Support, wenn ein Kunde anruft und behauptet, die eine Buchung aus dem Jahr 2005 sei falsch.

Zitat:

Zitat von Dejan Vu (Beitrag 1283678)

PS: XML in einen Server geht genauso schnell und das Aufdröseln in Tabellen auch. Sind halt ein paar Zeilen mehr. Einmalig.

Ein paar Zeilen mehr? Ich persönlich schramme bei der Oracle-XML-Syntax immer an meine geistige Kapazitätsgrenze. :cry:

Und, naja, daß ein Aufdröseln eines XMLs in relationale Tabellen so schnell geht wie der Import bereits aufgedröselter csv-Dateien - das bezweifle ich. Denkst du, das Aufdröseln gibt es umsonst?

Zitat:

Zitat von Dejan Vu (Beitrag 1283678)

Aber jedem das Seine. CSV hat jedenfalls imho in der professionellen Softwareentwicklung und im Datenaustausch, der etwas auf sich hält, nichts verloren. Das ist nicht abwertend, sondern in meinem Umfeld so.

Wir sind fürchterlich off-topic. Deshalb sag' ich dazu mal nix.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1283678)

Aber jedem das Seine. CSV hat jedenfalls imho in der professionellen Softwareentwicklung und im Datenaustausch, der etwas auf sich hält, nichts verloren. Das ist nicht abwertend, sondern in meinem Umfeld so.

Wenn Du eine nicht validierte XML-Datei bekommst, kannst Du Dich genauso auf die Nase legen, wie es mit einer CSV-Datei passieren kann. Schlimmer sind nur noch die Lieferanten, die grundsätzlich den Industriestandard EXCEL nutzen und sich dann wundern, daß bei 65.000 Zeilen Schluß ist, falls sie es überhaupt bemerken.

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von smallie (Beitrag 1283689)

Und, naja, daß ein Aufdröseln eines XMLs in relationale Tabellen so schnell geht wie der Import bereits aufgedröselter csv-Dateien - das bezweifle ich. Denkst du, das Aufdröseln gibt es umsonst?

Die Daten waren vorher (CSV) tabellarisch, dann werden sie es als XML wohl kaum nicht mehr sein. D.h. die Struktur ändert sich ja nicht, wohl aber das Format. Es geht aber imho nicht um die paar Sekunden beim Import (wenn Oracle hier zu umständlich ist, dann schreibt man ein XSLT, das die Daten umdröselt, und zwar in das Format, das das Bulk Insert von Oracle am besten beherrscht. Kann auch CSV sein ;-) )
Wichtig ist doch, das man mit externen Zulieferern belastbare Vereinbarungen trifft, die jeder einhalten kann, und die zudem mit frei verfügbaren Tools ('XML Validator') nachzuprüfen sind. Ich kann in meinen Vertrag ja auch schreiben, das eine Datei erst dann akzeptiert wird, wenn sie mit Hilfe der XSD auf www.xmlvalidator.com validiert werden kann.

Zitat:

Zitat von p80286 (Beitrag 1283695)

Wenn Du eine nicht validierte XML-Datei bekommst, kannst Du Dich genauso auf die Nase legen, wie es mit einer CSV-Datei passieren kann. Schlimmer sind nur noch die Lieferanten, die grundsätzlich den Industriestandard EXCEL nutzen und sich dann wundern, daß bei 65.000 Zeilen Schluß ist, falls sie es überhaupt bemerken.

Vollkommen korrekt. Das Stichwort ist 'nicht validiert'. Wenn ich Daten bekommen soll, wird darüber eine schriftliche Vereinbarung getroffen. Bestandteil des Vertrages ist die XSD. Das kann man auch intern so regeln (es muss ja kein Vertrag sein, Kollegen erfüllen auch mündliche Vereinbarungen)

Das das intern nicht so einfach ist oder -noch schlimmer- bei Kunden gar nicht durchsetzbar ist, steht auf einem anderen Blatt. Aber wenn ich o.g. Prämisse nicht mit den eingehenden Rohdaten bekomme, dann schreibe ich mir einen Filter, der das exotische Fremdformat in mein einheitliches Import-Format übersetzt. Und das geht dann durch den Importer.

Die Krönung ist der Datenlieferant aus den o.g. Zulieferern, der seine Daten in Word als Tabelle formatiert, aber jedes mal von einem anderen Praktikanten und sich dann wundert, das man das nur abtippen kann und nicht elektronisch einlesen. Aber ein sich änderndes CSV-Format ist auch nicht schlecht. Wir sollten echt einen WTF-Thread aufmachen.