CSV Datei import/export
23. März 2006 17:00
Hi,
kann es sein, dass Navision nicht so ganz begreift wie man eine korrekte CSV Datei erstellt/einliest ?
Wenn ich als start/end Delimeter ein " und als Feldtrenner ; einstelle und ich ein Feld exportiere, das auch ein " enthält wird das nicht escaped und das kann ich dann über den gleichen Dataport auch nicht mehr einlesen ... excel verdoppelt es, andere würden ein \ davor stellen, aber Navision ?
--
MfG Stefan
kann es sein, dass Navision nicht so ganz begreift wie man eine korrekte CSV Datei erstellt/einliest ?
Wenn ich als start/end Delimeter ein " und als Feldtrenner ; einstelle und ich ein Feld exportiere, das auch ein " enthält wird das nicht escaped und das kann ich dann über den gleichen Dataport auch nicht mehr einlesen ... excel verdoppelt es, andere würden ein \ davor stellen, aber Navision ?
--
MfG Stefan
23. März 2006 17:55
hi bm_
wenn mich nicht alles täuscht darfst du als delimter keine zeichen verwenden die im file vorkommen.
was für eine art von csv verwendest du MS-Dos? Trennzeichen?
sonst empfiehlt es sich das ganze noch über eine normales *.txt file einzulesen.
Das funkt. am besten.
hoffe ich konnte dir weiterhelfen
mfg
dante
wenn mich nicht alles täuscht darfst du als delimter keine zeichen verwenden die im file vorkommen.
was für eine art von csv verwendest du MS-Dos? Trennzeichen?
sonst empfiehlt es sich das ganze noch über eine normales *.txt file einzulesen.
Das funkt. am besten.
hoffe ich konnte dir weiterhelfen
mfg
dante
23. März 2006 21:21
Es ist richtig: Die verwendeten Trennzeichen dürfen nicht in einem der zu exportierenden Werte enthalten sein. Navision "escaped" kollidierende Zeichen nicht.
Das Einfachste wäre, die Start-/End-Delimiter einfach beim Export wegzulassen (also auf <None> stellen) und als Feldtrennzeichen die Pipe (also | ) wählen.
So ist die Kollisionsgefahr am geringsten.
Dies nutzen wir schon seit Jahren erfolgreich und hatte bisher noch nie Probleme damit.
Ach ja: Kleiner Hinweis: Navision exportiert immer im ASCII-Modus, Excel hätte jedoch gerne ANSI.
Workarounds:
1. Nicht in eine *.csv-Datei, sondern in eine *.txt-Datei exportieren, dann kann in Excel die Zeichenkodierung ausgewählt werden.
2. Den zu exportierenden Text von ASCII nach ANSI konvertieren.
Das Einfachste wäre, die Start-/End-Delimiter einfach beim Export wegzulassen (also auf <None> stellen) und als Feldtrennzeichen die Pipe (also | ) wählen.
So ist die Kollisionsgefahr am geringsten.
Dies nutzen wir schon seit Jahren erfolgreich und hatte bisher noch nie Probleme damit.
Ach ja: Kleiner Hinweis: Navision exportiert immer im ASCII-Modus, Excel hätte jedoch gerne ANSI.
Workarounds:
1. Nicht in eine *.csv-Datei, sondern in eine *.txt-Datei exportieren, dann kann in Excel die Zeichenkodierung ausgewählt werden.
2. Den zu exportierenden Text von ASCII nach ANSI konvertieren.
Re: CSV Datei import/export
24. März 2006 11:33
Hallo Stefan,
Wie sieht denn so eine korrekte CSV-Datei aus?
Gruß, Marc
bm_ hat geschrieben:kann es sein, dass Navision nicht so ganz begreift wie man eine korrekte CSV Datei erstellt/einliest ?
Wie sieht denn so eine korrekte CSV-Datei aus?
Gruß, Marc
24. März 2006 17:39
beispielsweise so wie hier beschrieben: http://www.ietf.org/rfc/rfc4180.txt
Trennzeichen sollte man halt schon in den Daten selbst verwenden können.
Trennzeichen sollte man halt schon in den Daten selbst verwenden können.
27. März 2006 15:15
@Stefan: Danke für den Link.
28. März 2006 19:10
bm_ hat geschrieben:Trennzeichen sollte man halt schon in den Daten selbst verwenden können.
Da kann ich nur von abraten, schon weil die visuelle Lesbarkeit der Textdateien extrem darunter leidet und eine mögliche Fehlersuche unnötig erschwert wird.
OpenOffice 2.0 ist mittlerweile sehr flexibel beim Spreadsheet-Export, Trennzeichen, Feldbegrenzer und Codepage können vor dem Textexport einfach eingestellt werden.
28. März 2006 20:16
Timo Lässer hat geschrieben:Das Einfachste wäre, die Start-/End-Delimiter einfach beim Export wegzulassen (also auf <None> stellen) und als Feldtrennzeichen die Pipe (also | ) wählen. So ist die Kollisionsgefahr am geringsten.
Ich kann das nur bestätigen. Ich habe schon dutzende von Importen/Exporten programmieren müssen und bin mit dieser Lösung am besten gefahren. Ausser in Navisionfiltern habe ich den Pipe | praktisch noch nie verwendet in irgendwelchen Texten.
29. März 2006 07:24
Hallo,
mein Beitrag ist nicht direkt CSV - Relevant, aber könnte für weitere Schnittstellen hilfreich sein!
Ich musste mal einen Report / Dataport erstellen, der ein SQL lesbaren Code erstellt.
Da in SQL die Werte in Hochkommas (') gefasst sind, musste ich ganz schön Probieren, bis es Funktionierte.
Rätsels Lösung waren 4 Hochkommas, damit Navision 1 Hochkomma Exportiert und keine Fehler beim Kompilieren ausgibt!
Beispiel:
MESSAGE('''');
-->Ausgabe = '
Zusätzlich problematisch, wenn in den Quelldaten im Text Hochkommas sind!
Gruß Mikka
mein Beitrag ist nicht direkt CSV - Relevant, aber könnte für weitere Schnittstellen hilfreich sein!
Ich musste mal einen Report / Dataport erstellen, der ein SQL lesbaren Code erstellt.
Da in SQL die Werte in Hochkommas (') gefasst sind, musste ich ganz schön Probieren, bis es Funktionierte.
Rätsels Lösung waren 4 Hochkommas, damit Navision 1 Hochkomma Exportiert und keine Fehler beim Kompilieren ausgibt!
Beispiel:
MESSAGE('''');
-->Ausgabe = '
Zusätzlich problematisch, wenn in den Quelldaten im Text Hochkommas sind!
Gruß Mikka
26. April 2006 20:15
Hilfe 
ich komme mit einem Dataport nicht weiter.
Ich habe eine Exeldatei in der so ziemlich alles an Zeichen vorkommt, was der User benutzten kann, ausnahmen sind das PIPE Zeichen | und die Tilde ~.
Egal wie ich die Datei Speichere, ich bekomme immer Probleme.
Als *.csv ist ungeeignet, da das Semikolon vorkommt.
Ich habe versuchshalber einzelne Zeilen eingefügt mit dem PIPE, hatte ich auch keinen Erfog mit.
Ich kann bei mir keine Option finden um die Zeichenkodierung zu wählen. Wir haben Office 2000 im Installiert.
Wer kann mir detailiert schreiben, wie ich die Datei Speichern muss und wie ich den Dataport konfigurieren muss.
Danke für jeden Beitrag, bei mir Brennt es!
Gruß Mikka
ich komme mit einem Dataport nicht weiter.
Ich habe eine Exeldatei in der so ziemlich alles an Zeichen vorkommt, was der User benutzten kann, ausnahmen sind das PIPE Zeichen | und die Tilde ~.
Egal wie ich die Datei Speichere, ich bekomme immer Probleme.
Als *.csv ist ungeeignet, da das Semikolon vorkommt.
Ich habe versuchshalber einzelne Zeilen eingefügt mit dem PIPE, hatte ich auch keinen Erfog mit.
Timo hat geschrieben:Workarounds:
1. Nicht in eine *.csv-Datei, sondern in eine *.txt-Datei exportieren, dann kann in Excel die Zeichenkodierung ausgewählt werden.
2. Den zu exportierenden Text von ASCII nach ANSI konvertieren.
Ich kann bei mir keine Option finden um die Zeichenkodierung zu wählen. Wir haben Office 2000 im Installiert.
Wer kann mir detailiert schreiben, wie ich die Datei Speichern muss und wie ich den Dataport konfigurieren muss.
Danke für jeden Beitrag, bei mir Brennt es!
Gruß Mikka
26. April 2006 20:57
Ich würde als Trennzeichen immer eine Zeichenfolge nehmen z.B. ##### oder ein nicht druckbares Zeichen z.B. <TAB> das sollte so nie in einer Datei vorkommen.
Erstellen tue ich eine solche <TAB> Datei indem ich die Daten aus Excel in einen Editor kopiere z.B. Scite und dann als DOS.txt speichere.
Falls <Tabs> in den Daten vorkommen habe ich noch keinen anderen Weg gefunden als in Excel zwischen jede Spalte eine Spalte mit den Trennzeich (z.B. ##### oder |||||) zu legen (geht gut mit einem Macro) und dann als text zu Exportieren.
Erstellen tue ich eine solche <TAB> Datei indem ich die Daten aus Excel in einen Editor kopiere z.B. Scite und dann als DOS.txt speichere.
Falls <Tabs> in den Daten vorkommen habe ich noch keinen anderen Weg gefunden als in Excel zwischen jede Spalte eine Spalte mit den Trennzeich (z.B. ##### oder |||||) zu legen (geht gut mit einem Macro) und dann als text zu Exportieren.
26. April 2006 20:58
mikka hat geschrieben:[...]Timo hat geschrieben:Workarounds:
1. Nicht in eine *.csv-Datei, sondern in eine *.txt-Datei exportieren, dann kann in Excel die Zeichenkodierung ausgewählt werden.
2. Den zu exportierenden Text von ASCII nach ANSI konvertieren.
Ich kann bei mir keine Option finden um die Zeichenkodierung zu wählen. Wir haben Office 2000 im Installiert.
[...]
Du kannst mit Hilfe der Codeunit TextManagement aus dem Download Center den Text nach ANSI konvertieren, bevor du ihn exportierst.
Navision exportiert immer nur im ASCII-Format, daher muss der zu exportierende Text von ASCII nach ANSI konvertiert werden:
MyExportField := TxtMgt.ASCII2ANSI(MyExportField);
26. April 2006 21:34
Danke für Eure Beiträge,
ich habe eben noch den Tipp bekommen die Daten in Access einzulesen und dann als *.txt zu Exportieren.
Bei der ersten Datei hat das geklappt, der Import nach Navision auch.
Ich hoffe das es gleich auch mit der andern Datei Funktioniert.
@Beni
Mit TAB separierten Daten stehe ich auf Kriegsfuß, die mögen mich nicht!
An mehrere Trennzeichen habe ich bisher noch nie gedacht, das geht!?
Wenn ja, sollte Eigentlich kein Dataport mehr Probleme bereiten.
@Timo
Danke für den Hinweiß, aber mit der Konvertierung habe ich zu Glück keine Probleme.
Mir ist nur nicht klar, wie ich Excel sagen kann, das es die Trennzeichen anders behandeln soll, ich denke das es an unserer Officeversion liegt!
Gruß Mikka
ich habe eben noch den Tipp bekommen die Daten in Access einzulesen und dann als *.txt zu Exportieren.
Bei der ersten Datei hat das geklappt, der Import nach Navision auch.
Ich hoffe das es gleich auch mit der andern Datei Funktioniert.
@Beni
Mit TAB separierten Daten stehe ich auf Kriegsfuß, die mögen mich nicht!
An mehrere Trennzeichen habe ich bisher noch nie gedacht, das geht!?
Wenn ja, sollte Eigentlich kein Dataport mehr Probleme bereiten.
@Timo
Danke für den Hinweiß, aber mit der Konvertierung habe ich zu Glück keine Probleme.
Mir ist nur nicht klar, wie ich Excel sagen kann, das es die Trennzeichen anders behandeln soll, ich denke das es an unserer Officeversion liegt!
Gruß Mikka
27. April 2006 10:32
Hallo,
neuer Tag, die gleichen Probleme.
Ich habe meine Datei jetzt mit der Geschweiften Klammer Separiert '}' als FieldStartDelimiter / FieldEndDelimiter.
Als Field separator habe ich ein PIPE Zeichen '|'.
Das klappt auch bis zur 402 Zeile, dann Fehler!
Nach wie vor bekomme ich einen Importfehler, das Feld xxx muss YYY sein. Es handelt sich um ein OPTION Field.
Also ist das ein Zeichen für mich, das der Report vermutlich an der zeile 403 abbricht, da in diesen Bereich er ein Feld mehr erkannt hat wie er sollte.
Beim sichten der Datei, kann ich allerdings nichts finden.
Wer kann mir einen guten Tipp geben, wie ich den Fehler besser finde?
Danke für jeden Vorschlag. (Ich muss die Daten schnellst möglich Importieren!!!)
Gruß Mikka
neuer Tag, die gleichen Probleme.
Ich habe meine Datei jetzt mit der Geschweiften Klammer Separiert '}' als FieldStartDelimiter / FieldEndDelimiter.
Als Field separator habe ich ein PIPE Zeichen '|'.
Das klappt auch bis zur 402 Zeile, dann Fehler!
Nach wie vor bekomme ich einen Importfehler, das Feld xxx muss YYY sein. Es handelt sich um ein OPTION Field.
Also ist das ein Zeichen für mich, das der Report vermutlich an der zeile 403 abbricht, da in diesen Bereich er ein Feld mehr erkannt hat wie er sollte.
Beim sichten der Datei, kann ich allerdings nichts finden.
Wer kann mir einen guten Tipp geben, wie ich den Fehler besser finde?
Danke für jeden Vorschlag. (Ich muss die Daten schnellst möglich Importieren!!!)
Gruß Mikka
27. April 2006 10:48
Hallo mikka
Ich verzichte eigentlich immer auf FieldStartDelimiter/FieldEndDelimiter. Die setze ich jeweils auf <None>. Für die Trennung der Felder vewende ich meistens das Sekimolon oder ein Pipe (lieber aber ; )
Wenn nun ein Fehler beim Import auftaucht, der darauf schliessen lässt, dass irgendwo im Text ein ; vorhanden ist, das die Felderanzahl durcheinanderbringt, öffen ich das TXT-File mit Excel um gebe dort als Trennzeichnen ; an.
Jetzt habe ich die Felder schön in Spalten und die Feldtrennzeichen sind weg. Mit Suchen/Ersetzen ändere ich alle ; in : und speichere die Datei wieder als CSV (MSDOS) (*.csv).
In der Regel klappt der Import anschliessend.
Ich verzichte eigentlich immer auf FieldStartDelimiter/FieldEndDelimiter. Die setze ich jeweils auf <None>. Für die Trennung der Felder vewende ich meistens das Sekimolon oder ein Pipe (lieber aber ; )
Wenn nun ein Fehler beim Import auftaucht, der darauf schliessen lässt, dass irgendwo im Text ein ; vorhanden ist, das die Felderanzahl durcheinanderbringt, öffen ich das TXT-File mit Excel um gebe dort als Trennzeichnen ; an.
Jetzt habe ich die Felder schön in Spalten und die Feldtrennzeichen sind weg. Mit Suchen/Ersetzen ändere ich alle ; in : und speichere die Datei wieder als CSV (MSDOS) (*.csv).
In der Regel klappt der Import anschliessend.
27. April 2006 11:10
Hallo Rotsch,
danke für deinen Beitrag.
Ich habe den Fehler gefunden.
Das von mir zuvor erwährte OPTION Field war der Verursacher.
Ich habe in diesem String ein Wort mit einem 'ü' drin und Vergessen diesen String zu Konvertieren in das Navision Format
Die von dir Erwähnten Semikolons benutze ich sonst auch, aber in dieser Datei müssen die drin bleiben
Dankeschön an Euch
Gruß Michael
@bm_
Falls das Toppic für dich auch als [Gelöst] gilt, würde ich den Beitrag gerne auf [Gelöst] setzten. Das kannst du auch machen wenn du möchtest!
danke für deinen Beitrag.
Ich habe den Fehler gefunden.
Das von mir zuvor erwährte OPTION Field war der Verursacher.
Ich habe in diesem String ein Wort mit einem 'ü' drin und Vergessen diesen String zu Konvertieren in das Navision Format
Die von dir Erwähnten Semikolons benutze ich sonst auch, aber in dieser Datei müssen die drin bleiben
Dankeschön an Euch
Gruß Michael
@bm_
Falls das Toppic für dich auch als [Gelöst] gilt, würde ich den Beitrag gerne auf [Gelöst] setzten. Das kannst du auch machen wenn du möchtest!
27. April 2006 11:47
mikka hat geschrieben:Die von dir Erwähnten Semikolons benutze ich sonst auch, aber in dieser Datei müssen die drin bleiben
Na Hauptsache, du konntest das Problem lösen in der benötigten Frist.
29. April 2006 02:20
hier noch ein Tip dazu, der das umwandeln in Ascii erspart.
Wenn man die Excel tabelle speichert, wählt man ziemlich unten in der Liste der Dateitypen, den Eintrag Text(MSDOS) und erhält eine Datei im Ascii Format mit TAB als Feldtrenner.
Diese lässt sich direkt mit dem Dataport einlesen.
Wenn man die Excel tabelle speichert, wählt man ziemlich unten in der Liste der Dateitypen, den Eintrag Text(MSDOS) und erhält eine Datei im Ascii Format mit TAB als Feldtrenner.
Diese lässt sich direkt mit dem Dataport einlesen.
29. April 2006 10:35
Hallo,
danke nochmals für Eure Beiträge.
Als kleinen Tipp kann ich noch erwähnen, das mit Access die Daten leichter aufzubereiten sind, als mit Excel, kommt allerdings auch daruf an was gemacht werden muss. Selbst eine Liste mit nur 200 Eiträgen war besser aufzuarbeiten.
Access bietet beim Exportieren der Datei auch mehr möglichkeiten, z.B. Das Texterkennungskennzeichen sebst anzugeben. In Excel können nur die Vorgegebenen ausgewählt werden.
Bei Excel habe ich festgestellt, das Daten manchmal ganz schön durcheinander gewürfelt wurden! Des weiteren hatte ich Artikelnr. wie dieses z.B.
40.0012
Excel hat daraus 400.012 gemacht, das Program hat den PUNKT als Dezimaltrennzeichen erkannt und Verschoben
Gruß Mikka
danke nochmals für Eure Beiträge.
Als kleinen Tipp kann ich noch erwähnen, das mit Access die Daten leichter aufzubereiten sind, als mit Excel, kommt allerdings auch daruf an was gemacht werden muss. Selbst eine Liste mit nur 200 Eiträgen war besser aufzuarbeiten.
Access bietet beim Exportieren der Datei auch mehr möglichkeiten, z.B. Das Texterkennungskennzeichen sebst anzugeben. In Excel können nur die Vorgegebenen ausgewählt werden.
Bei Excel habe ich festgestellt, das Daten manchmal ganz schön durcheinander gewürfelt wurden! Des weiteren hatte ich Artikelnr. wie dieses z.B.
40.0012
Excel hat daraus 400.012 gemacht, das Program hat den PUNKT als Dezimaltrennzeichen erkannt und Verschoben
Gruß Mikka
29. April 2006 10:41
In Version 4.0 SP1 gibt es jetzt Standardmässig eine Möglichkeit, Daten zu importieren und exportieren, ohne das man programmieren muss. Ich habe dazu ein paar Stichworte in einem Worddokument festgehalten (nicht vollständig und nur als Entwurf, rsp. Gedankenanstoss)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
29. April 2006 14:16
Ich benutze besonders bei großen Datenmengen immer Access. Excel (zumindest die 2000er Version, die ich seinerzeit für einen Artikelstamm benutzt habe) macht bei größeren Tabellen (so ab 30000 Zeilen) Fehler beim Kopieren der Zelleninhalte über die Zwischenablage. Beim Einfügen sind die Werte in den Zielzellen dann mehrmals vorhanden gewesen.
Wenn wirkliche Schrottdaten in Form zu bringen sind, kann man am Anfang beim häppchenweisen Aufbereiten mit Excel am schnellsten klarkommen. Danach ist Access aber geeigneter. Alleine schon die Access-Duplikatprüfung sollte immer am Schluss in einigen Feldern immer laufen, um die Daten vor dem Einlesen nochmal zu prüfen.
Wenn wirkliche Schrottdaten in Form zu bringen sind, kann man am Anfang beim häppchenweisen Aufbereiten mit Excel am schnellsten klarkommen. Danach ist Access aber geeigneter. Alleine schon die Access-Duplikatprüfung sollte immer am Schluss in einigen Feldern immer laufen, um die Daten vor dem Einlesen nochmal zu prüfen.
29. April 2006 14:26
Kowa hat geschrieben:... macht bei größeren Tabellen (so ab 30000 Zeilen) Fehler beim Kopieren ...
Das habe ich so noch nicht bemerk, kann ich mir aber schon vorstellen. Bei rund 64000 Zeilen ist ja eh Ende der Fahnenstange bei Excel. Laut Microsoft soll aber diese Grenze mit der nächsten Version (Office 12) fallen. Man darf gespannt sein.