Shortcut IT hat geschrieben: ↑13.04.2023 11:26
In dem Zusammenhang: da du von einer Cloud-Anwendung geschrieben hast, vermute ich, dass die eher auf einem Unix-System als auf einem Windows-System läuft. Windows ist mit dem 2-Byte-Zeilenumbruch (CR+LF) etwas exotisch, Unix-Systeme verwenden nur das LF. Von daher, bist du dir mit CL_ABAP_CHAR_UTILITIES=>CR_LF sicher oder wäre CL_ABAP_CHAR_UTILITIES=>LINEFEED ggf. doch der richtige Zeilenumbruch
Das sollte keine Rolle spielen, denn der Typ, der das empfangende System betreut, hat über die "Leerzeile am Ende" gemeckert, nicht darüber, dass er auch mit den davorliegenden Zeilen ein Problem gehabt hätte. Im übrigen akzeptiert sein System auch csv-Dateien, die manuell in Excel zusammengebastelt worden sind. Und Excel bedeutet Windows.
adt hat geschrieben:Persönlich finde ich aber die Variante mit eigenem Zusammenbauen eines Strings mit den gewünschten Zeilentrennzeichen, anschließender Codepagekonvertierung in einen xstring und schließlich schreiben im BINARY MODE wesentlich flexibler.
In dem Moment, in dem man die Flexibilität braucht, hast Du recht. Normalerweise sollte es aber ausreichen, Textdateien mit den ABAP-Bordmitteln zu erzeugen, und das ist dann deutlich kürzer und besser lesbar
(und vermutlich auch performanter). Von daher sollte man keinen programmiertechnischen Aufwand treiben, wo man ihn nicht braucht. Sonst ist das, als ob man immer alle Felder dynamisch mit REF TO definieren würde mit der Begründung, dass das ja flexibler sei.
Hier war die Flexibilität deshalb für mich nötig, weil ich diesem Fehler auf die Spur kommen wollte, und damit der Aufwand gerechtfertigt.