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

[malzusrex]

Die Function kam mit 7.3 TR 6 auf die Maschine. Der Sourcecode der Function kann mit dem Navigator eingesehen werden, damit ist es möglich, diese Function auf einem älteren Release zu implementieren.

Allerdings müsste man dann einen Zugang zu einer Maschine haben, welche mindestens auf 7.3 TR6 läuft....

Aber wir sollen ja dieses Jahr eine neue Maschiene bekommen. Freun mich dann schon es probieren zu können.

Und ich finde alle Lösungen okay. Immer wieder schön zu sehen, dass viele Weg nach Rom führen ;-)

Liebe Grüße
Ronald

[Fuerchau]

Ich bekomme auch gerne Dateien mit mehr als 10000 Zeilen;-).
Da würde ich dir eher eine Table-Function nach Birgittas Methode mit einzelnem Satz-Return empfehlen.
Nach deiner Methode scheiterst du an der 16MB-Grenze;-).
Auch die Split-Funktion wird da eine wohl eine ähnliche Grenze haben.

Nach dem Fetch steht die Anzahl der Zeilen bereits in der SQLCA SQLER3;-).

[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.

[holgerscherer]

Allerdings müsste man dann einen Zugang zu einer Maschine haben, welche mindestens auf 7.3 TR6 läuft....

zum Testen wüsste ich da ja was ;-)

Und ansonsten gilt wie immer: der GF auf die Füsse treten, daß auch die IT am Ball bleibt. Wir kennen alle die Diskussionen, aber erstaunlicherweise ist leider gerade unser Markt da sehr hartnäckig, Altblech zu betreiben.
(Und das schreibe ich als jemand, der zwangsweise für einen Kunden eine CISC-Maschine betreibt...)