[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    May 2012
    Beiträge
    19

    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.

  2. #2
    Registriert seit
    Jun 2001
    Beiträge
    1.601
    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
    Interessante Umfrage zur Nutzung der AS/400

  3. #3
    Registriert seit
    May 2012
    Beiträge
    19
    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.

  4. #4
    Registriert seit
    Jun 2001
    Beiträge
    1.601
    Neue Sitzung,

    debug auf das Pgm
    break nach dem update
    Job ansehen
    - ovr,
    - offene Dateien,
    - Joblog

    Es gibt immer einen Grund!
    Interessante Umfrage zur Nutzung der AS/400

  5. #5
    Registriert seit
    Feb 2001
    Beiträge
    17.720
    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).
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  6. #6
    Registriert seit
    May 2012
    Beiträge
    19
    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.

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    17.720
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #8
    Registriert seit
    May 2012
    Beiträge
    19
    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.

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    17.720
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #10
    Registriert seit
    May 2012
    Beiträge
    19
    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.

Ähnliche Themen

  1. INSERT-Problem
    Von AKS1 im Forum NEWSboard programmierung
    Antworten: 6
    Letzter Beitrag: 26-03-18, 17:01
  2. Datenumsetzung in AS400-Tabellen
    Von alex61 im Forum System i Hauptforum
    Antworten: 1
    Letzter Beitrag: 12-08-16, 16:44
  3. insert 32768
    Von Armin im Forum NEWSboard programmierung
    Antworten: 17
    Letzter Beitrag: 19-12-14, 13:07
  4. SQL V5R4 Insert into
    Von KingofKning im Forum NEWSboard programmierung
    Antworten: 7
    Letzter Beitrag: 10-10-14, 09:13
  5. Datenumsetzung von V3R2 in V2R3
    Von Günter Majewski im Forum System i Hauptforum
    Antworten: 5
    Letzter Beitrag: 03-07-02, 10:09

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •