*.csv oder *.txt mit einer Datensatz-Größe von mehr als 32 MB

[votch]

Hallo zusammen und vielen Dank für die Antworten.
Ich war die letzten Tage unterwegs und konnte daher erst heute antworten.
Bei der *.csv stehen in der 1. Zeile immer Feldnamen und in Zeile 2-n die zugehörigen Daten. Anzahl/Reihenfolge der Felder ist variabel, ob die Daten korrekt sind muss vor Übernahme ins ERP-System geprüft werden. Die Datei wird maschinell oder manuell erstellt und die Anzahl der Sätze hängt vom Prozess/User ab, das können z.B. 5 Sätze mit 1000 Feldern, 20.000 Sätze mit 5 Feldern aber theoretisch auch 50.000 Sätze mit 1000 Feldern sein.
Eine bestehende Lösung gibt es bereits, sie basiert auf einem CPYFRMIMPF und einem tab-getrennten *.txt-File. Für den CPYFRMIMPF wird eine PF mit 150 Feldern (80A) benutzt, da unklar ist, ob z.B. in der 1. Spalte eine Beschreibung(80A) oder ein Wert(13,5) oder etwas Anderes steht. Nach dem CPYFRMIMPF wird der erste Satz mit den Feldnamen aus der PF gelesen und für die einzelnen Feldnamen die Definition(Feldart/Feldlänge) aus den bereits bestehenden ERP-Dateien ermittelt und alles in eine Tabelle geschrieben.
Anschließend werden die Sätze 2-n verarbeitet und inhaltlich gegen die Tabelle geprüft, so dass z.B. in einem mit 5S2 definierten Feld keine Buchstaben, 6 Vorkomma- oder 4 Nachkomma-Stellen stehen. Bei ungültigen Feldnamen wird das komplette File, bei ungültigen Daten der falsche Datensatz mit Fehlerprotokoll abgelehnt. Später folgen dann noch weitere Prüfungen aufgrund der vorhandenen Business-Logik.
Mittlerweile reichen die 150 Felder der alten Lösung nicht mehr aus, da es bereits Artikel gibt mit mehr als 1.000 Feldern bzw. zusätzlichen Artikel-Angaben.
Da ich beim CPYFRMIMPF eine PF mit 1000 Feldern(80A) bräuchte, die sich aber wegen der DS-Größe nicht kompilieren lässt, werde ich mein Glück mal mit SPLIT(), GET_CLOB_FROM_FILE und "CLOB"-Variablen versuchen. Ein Kurz-Test mit interaktivem SQL sah vielversprechend aus…

[Fuerchau]

Tut mir Leid, das ist aber der falsche Ansatz.
Wenn du den obigen SQL ebenso pauschalisierst, wirst du ebenso an der 32-KB-Grenze scheitern.
Dies ist aber nicht Sinn und Zweck eines CPYFRMIMPF.
Für jeden Typ einer CSV-Datei lege ich mir eine individuelle Importtabelle an, deren Feldtypen genau dem erwarteten entsprechen. Da gibt es das 32-KB-Probelm überhaupt nicht.
Desweiteren erfolgt beim Import bereits die Typprüfung, Fehler lassen sich in einer Protokolldatei ausgeben.
Jeder Import sollte individualisiert werden, damit die nachfolgende Verarbeitung erheblich vereinfacht werden kann.

https://www.ibm.com/support/knowledg...cpyfrmimpf.htm
RMVCOLNAM entfernt automatisch die Kopfzeile.