-
INSERT INTO Datenumsetzung ?
Hallo,
brauche mal wieder Hilfe, stehe absolut kein Licht im Dunkel.
Folgendes:
In einem Modul steht:
/exec sql
+ INSERT INTO DATEI VALUES(:INHALT)
/end-exec
Der Insert brauch sehr viel Zeit (nicht mal 10000 sätze in 4 Minuten)
Die Datei hat nur ein AlphaFeld und wurde mit CRTPF ohne DDS erzeugt.
Nun meldet das JobLog jedesmal "Datenumsetzung für Anweisung INSERT oder UPDATE erforderlich."
Noch erstaunlicher für mich ist dass auch das Feld welches die Datenumsetzung erforderlich macht angegeben ist , es ist zu meiner Verwunderung "SRCSEQ" .
Was hat denn nun dieses Feld (glaube das kommt aus der SourceDatei) mit meiner Datei zu schaffen und warum muss überhaupt eine Datenumsetzung passieren ?
Hoffe ich habe alles entscheidende angegeben wenn nicht bitte nachfragen.
Vielen Dank
Gruß Volker.
-
Die Aussagen passen nicht zueinander.
CRTPF ohne DDS erzeugt eine Datei mit einem Feld, das Feld heist wie die Datei.
SRCSEQ ist, wie du schon schreibst, aus einer PF-SRC
Habt ihr das PGM geändert? nicht ILE / ILE
Fehlt OVRDBF oder ist er nicht mehr gültig da er bisher auf *actgrp statt auf *job lief )
Ist plötzlich ein OVRDBF da
Heist die Datei wirklich Datei
gibt es Sie in der Liblist öfter?
WGN Performance:
versuch
/exec sql
+ INSERT INTO DATEI set DATEI = :INHALT
/end-exec
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Hallo
Danke für die Antwort.
Wenn ich mir die Felder über DSPFFD ansehe dann ist das natürlich auch so Feldname und Dateiname sind gleich
Die Datei heisst nicht DATEI die heisst CSV
Insert mit Feldnamen habe ich probiert (allerdings ohne Set) gleiches Ergebniss.
Datei steht in QTEMP keine Overrides im spiel und es gibt sie auch nur einmal.
ACTGRP ist NEW und der Insert ist in einem Modul (da ist dann NOMAIN) angegeben.
Leider habe ich bei uns auch kein anderes MODUL gefunden welches UPDATE oder INSERT macht das passiert im RPG.
Ich verstehe das nicht.
Gruß Volker.
-
Neue Sitzung,
debug auf das Pgm
break nach dem update
Job ansehen
- ovr,
- offene Dateien,
- Joblog
Es gibt immer einen Grund!
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Die Datenumsetzung erfolgt, da die PF keine CCSID hat (*HEX) und du eben einen Insert ggf. mit CCSID machst (Job).
Die Performance rührt nun daher, dass du wohl nur 1 Insert im Modul machst und die ACTGRP dann verlässt: ACTGRP(*NEW).
Was also passiert:
- Erstellen einer ACTGRP
- ggf. Aufruf des Main-Programmes
- Aufruf deines Moduls
- Open der Zieldatei
- Insert
- Close der Zieldatei
- return's
- zerstören der ACTGRP
Hinzu kommt noch die Meldung der Datenumsetzung bei jedem Insert ins Joblog.
Ist doch klar, dass das dauert.
Besser wäre das Erstellen der Datei per SQL als Create Table. Da brauche ich auch keine DDS und die Ganze Aktion innerhalb eine ACTGRP durchführen, ggf. ACTGRP(*CALLER).
-
Hallo,
also der Fehler tritt nicht bei dem INSERT auf (entschuldigung dass mir das nicht gleich aufgefallen ist) sondern erst wenn die Datei ins IFS kopiert wird (CPYTOIMPF) das geht aber trotzdem relativ schnell komisch ist eben nur das Feld /SRCSEQ).
Um zu verhindern dass nach jedem INSERT der Cursor geschlossen wird habe ich in das Modul eine FeldGruppe eingebaut und erst wenn diese voll ist werden die INSERT statements ausgeführt und dann FG geleert und weitergefüllt das brachte die Verarbeitungszeit ja schon von 7 auf die 4 Min.
Nun habe ich noch das mit dem Create Tabel berücksichtigt und es waren auch noch sehr viele TRIMS (auch noch mit großen feldern) drin .
Nun bin ich bei fast 2 Minuten.
Kommt mir immer noch sehr langsam vor ohne den Modul aufruf sind es 40 sek.
Frage: wie bekomme ich das mit dem *CALLER hin das Hauptprogramm soll ja unter *NEW laufen und das worum es geht ist ja ein Modul ?
Viele Grüße und Danke nochmals
Volker.
-
Du beschreibst ein bisschen viel drum rum ohne konkret anzugeben was du genau machst.
Ein CPYTOIMPF kann gar keine PF, die mit CRTPF ohne Quelle ond somit mit CCSID *HEX erstellt wurde, da CPYTOIMPF immer eine CCSID der Quelle benötigt.
Also muss da noch ein Zwischenschritt (CPYF ggf. in eine SRC-PF) stattfinden.
Normalerweise sind die Calls nicht so sehr das Problem, wenn sie denn innerhalb einer ACTGRP aufgerufen werden.
Dein Modul kann ja nicht separat aufgerufen werden muss also in ein Programm eingebunden sein (CRTPGM oder CRTSVRPGM).
Service-PGM'e laufen immer in der selben ACTGRP wie der Aufrufer.
Wo bleibt die Zeit?
Kann es auch sein, dass du die Felder für die Übergabe per "CONST" übergibst?
Poste doch mal den vollständigen originalen SQL und wie die Aufbereitung der Felder ist.
-
Hallo,
den CPYTOIMPF benutze ich so:
'CPYTOIMPF FROMFILE(QTEMP/CSV)
TOSTMF(''&1'') MBROPT(*REPLACE)
STMFCODPAG(*PCASCII) RCDDLM(*CRLF)
STRDLM(*NONE) FLDDLM('';'')
DECPNT(*COMMA)'
in &1 steht dann nach einem replace der IFS Datei Name.
Warum das jetzt bei uns so geht ? es ist in vielen Prog.so ohne zwischenschritt , ich dachte immer das liegt an der angabe von STMFCODPAG.
Der Vollständige SQL besteht nur aus dem INSERT so wie ich es schon gepostet habe.
Zum Ablauf : es gibt 3 Module
Modul 1 kettet den übergebenen (als VALUE übergeben) Parameter mit ; getrennt zusammen
Modul 2 schrebt den zusammengeketteten String in die QTEMP/CSV
Modul 3 ermittelt das IFS Laufwerk und sendet
Mittlerweile habe ich den INSERT durch einen WRITE ersetzt (Datei per Open geöffnet und erst nach dem senden geschlossen) jetzt ist die geschwindigkeit wieder akzeptabel.
Mit viel auch auf dass ein Trim bei grossen Feldern sehr lange benötigt wenn ich per checkr das ende suche und dann genau dort einfüge (substr) dann geht das schneller wie die felder mit trim zusammenzufügen (jetzt müsste ich noch das ganze mit varchar probieren)
Was macht denn eigentlich der Parameter CLOSQLCSR (*ENDACTGRP oder *ENDMOD) beim erstellen des Moduls, da dachte ich eigentlich dass der genau dafür da ist , nämlich den cursor offen (jedenfalls bei ENDACTGRP) zu lassen.
Im JobLog stand aber auch immer OOP (Zugriffsweg ?) und nicht Cursor geschlossen (glaube ich jedenfalls , kann es nun nicht mehr nachvollziehen)
Viele Grüße
Volker.
-
Bzgl. des Trims hast du natürlich Recht.
Wenn das Zielfeld nicht vom Typ varying ist, muss das Ziel eben auch immer getrimmt werden.
Einfacher gehts per:
D MyCsvField 100 varying
clear MyCsvField;
dow bla;
MyCsvField += %trimr(MySourceField) + ";";
enddo;
Wofür brauchst du noch das Schreibmodul?
Warum machst du das nicht direkt im selben Modul?
CLOSQLCSR betrifft den SQL-Cursor, den es ja nur beim Select mit "Declare Cursor" gibt.
Das hätte den Vorteil, das der geöffnete Cursor beim Wiedereintritt ins Modul weitere Daten liefern könnte (z.B. Scrollcursor für seitenweise Blätteranzeigen).
Das hat fatale Auswirkungen wenn man SQL per OVRDBF austrickst, da ja die 1. Datei offen bleibt auch wenn man den OVRDBF ändert.
Dies hat nichts (bzw. nur indirekt) mit den OOP's zu tun.
SQL optimiert dahingehend, dass der einmal ermittelte Zugriffsweg beim 2. Auftreten geöffnet bleibt.
Somit entfällt das Analysieren, Optimieren und Öffnen der Tabelle/n.
Beim Verlassen einer ACTGRP werden die OOP's dann aber doch alle geschlossen, so dass hier ACTGRP(*NEW) ggf. kontraproduktiv ist.
-
Hallo ,
wahrscheinlich muss ich mir erst mal gedanken über die Verwendung von Modulen machen , denn so wie Du das bschreibst "direkt im selben Modul schreiben" , da kann ich gar nicht folgen.
Es gibt ein RPGLE da ist im Header eine Modulliste angegeben und es befindet sich eine CopyRoutine mit den ModulDefinitionen drin.
Nun wird irgendwo im Code zuerst das CSV feld gefüllt und dann in die Datei geschrieben und gesendet. Da habe ich dann nichts mehr davor und in dem RPGLE will ich es ja nicht haben (denn das muss ja in mehrere Programme rein).
Muss ich die einzelnen Module noch irgendwo zusammenfassen ?
Viele Grüße.
Similar Threads
-
By AKS1 in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 26-03-18, 16:01
-
By alex61 in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 12-08-16, 15:44
-
By Armin in forum NEWSboard Programmierung
Antworten: 17
Letzter Beitrag: 19-12-14, 12:07
-
By KingofKning in forum NEWSboard Programmierung
Antworten: 7
Letzter Beitrag: 10-10-14, 08:13
-
By Günter Majewski in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 03-07-02, 09:09
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks