CPYFRMIMPF (Tausenderpunkt)

[fpxx]

Hallo an alle,

ich habe ein Problem beim Import einer Csv-Datei mit CPYFRMIMPF, wenn ein numerisches Feld einen Tausenderpunkt enthält.
Fehlernachricht: Kopiervorgang aufgrund von Ursachencode 7 nicht durchgeführt.
Wie kann man das umgehen?

Vielen Dank für Eure Antwort(en)

[cbe]

Hallo,

ich denke dass das mit einer Spracheinstellung gelöst werden kann.

Wobei wir an dieser Stelle schon so häufig aus den verschiedensten Gründen Probleme hatten, dass ich CSV-Schnittstellen für numerische Daten immer nur noch ohne Punkt und Komma festlege. Also immer in kleinster Einheit (zB. Beträge in Cent, Gewichte in g, etc), und das Zielsystem teilt dann ggf. wieder entsprechend.
Klingt nach Steinzeit, aber funktioniert.

Gruß, Christian

[fpxx]

Hallo Christian,
die CSV-Dateien kommen von Kunden ins Haus; daher habe ich keinen Einfluss auf den Aufbau der CSV-Datei.

[Fuerchau]

CPYFRMIMPF ... DECPNT(*PERIOD)
Wenn das mangels Dezimalpunkt auf einen Fehler läuft, kannst du dann alternativ einen 2. Aufruf mit
CPYFRMIMPF ... DECPNT(*COMMA)
durchführen.

[Robi]

Der tausender Punkt in dem 'Numerischen' Feld macht das Feld zu einem Alpa Feld.
Ich glaube nicht das du den so wegbekommst.
Also: Zieldatei mit Alpa-Feldern definieren und per Pgm nach der Übername in die eigendliche Zieldatei umschubsen. Wir haben nur in den seltensten Fällen CSV-Datei Lieferanten, bei dehnen ein Num Feld
immer als NUM-Feld kam !
Robi

[Fuerchau]

CPYFRMIMPF ... DECPNT(*PERIOD)
hat bei mir immer geholfen.

[Robi]

Ok, das wäre mir neu.
*period ist bei uns der voreingestellte Wert.
Bleibe aber bei der 'zuerst nach Alpa' Methode. In eine CSV Datei kann sooooo viel Mist stehen.
(Bsp: Datumsfeld: kommt 5 mal als ttmmJJJJ und dann als 'schnellstens'

Robi

[fpxx]

Konkret steht in einem Datenfeld z.B. der Inhalt

1.750,00

In der Zieldatei der AS400 ist das Datenfeld mit 9 Stelllen, davon 2 Dezimalstellen definiert

Bei CPYFRMIMPF DECPNT(*COMMA), was dem Kommazeichen entspricht, können alle Inhalte < 1000 übernommen werden, die höheren, wenn mit Tausenderpunkt, werden nicht übernommen.
Bei DECPNT(*PERIOD) werden keine Sätze übernommen.

Ich kann mir auch nicht vorstellen, dass ein Parameter, der das Dezimalzeichen steuert, auch den Tausender-Punkt regelt.

[KingofKning]

Tja die hilft Dir wohl nur der Import in Excel und dann wieder als CSV speichern. Vielleicht kannst Du ja auch mit einem Editor . suchen und durch nichts ersetzen.GG

[fpxx]

Das sollte ein automatisierter Ablauf sein.

Wenn ich CSV als Excel öffne, habe ich das nächste Problem, dass dann andere Felder mit sehr langen "rein numerischen Inhalten" (zB. Tel.Nr. mit Ländervorwahl + Ortsvorwahl usw.) dann automatisch mit "E-Inhalten" im Excel dargestellt werden und beim Speichern (als CSV-Datei) dann auch mit diesen (unbrauchbaren) Inhalten gespeichert werden.

Hat dieses Problem mit den Tausenderpunkten bisher noch niemand gehabt?

[Robi]

Doch, hab ich doch geschrieben.
Definiere ALLE Felder der Zieldatei als alpa.
Schreibe ein mini Pgm, das via input/output die Felder prüft, formatiert und so ausgibt, wie du es brauchst.
Läuft hier bestimmt mit 20 Schnittstellen so!
Robi

[KingofKning]

Und was hälst Du dann davon, die Datei in eine Zwischendatei zu importieren, das Feld per SQL zu ändern und entweder dann per SQL in die richtige Datei schreiben Alpha-Feld per Cast in numerisch wandeln oder zu exportieren und dann in die richtige Datei zu importieren.Dürfte nicht viel Zeit kosten das zu realisieren. Alternativ habt Ihr jemanden der Cobol oder RPG kann.GG