[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Jan 2003
    Beiträge
    290

    Datensatz aus Trigger vor write (oder auch update) ändern

    Hallo zusammen,
    ich habe einige Trigger (RPG), die Dateien aus der 36-Umgebung (intern beschrieben)
    verarbeiten, in dem die Daten in ext.beschriebene Dateien "gespiegelt" werden.

    Jetzt habe ich neu eine Datei aus der S36-Umgebung, in dem numersiche Felder nicht korrekt initiiert sind, Inhalt ist x(40).
    An der S36-Umgebung kann ich nicht eingreifen, keine Quellen vorhanden.


    Kann ich im Trigger vor write den (getriggerten) Datensatz aus der S36-Umgebung ändern bzw. die num. Felder korrigieren ???
    ...ich habe es getestet und es scheint nicht zu funktionieren, die Felder sind zwar korrigiert (Debug im Trigger) , aber nicht nach Ende des Trigger in der Datei.

    Habe in der Doku nichts gefunden.

    Danke im Voraus.

  2. #2
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Ich nehme an es handelt sich um einen System-Trigger (in RPG oder Cobol).
    Damit gehe ich davon aus, dass der Trigger mit ADDPFTRG registriert wird.
    Jetzt die Frage:
    Wurde die Option "Wiederholte Änderung zulassen" (ALWREPCHG) beim Registrieren auf *YES gesetzt?
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  3. #3
    Registriert seit
    Jan 2003
    Beiträge
    290
    Birgitta,
    vielen Dank.
    Nein, der Parameter steht auf *NO, ist schon ein paar Jahre her dass ich die Trigger definiert habe.
    Die Trigger sind RPG-Programme.

    Ist das die Lösung, den Parameter auf *YES zu ändern ???

    Danke vorab.

  4. #4
    Registriert seit
    Nov 2004
    Beiträge
    325
    Moin,

    1. Klemm den Triger ab, Daten korrigieren, wieder anmachen
    oder
    2. Wenn das Triggerprogramm als Quelle da ist, schnell ein Return rein, Daten korrigieren, Programmänderung wieder rückgängig. (Wenn Datei nicht benutzt wird)

    mfg

    DKSPROFI

  5. #5
    Registriert seit
    Jan 2003
    Beiträge
    290
    Jeder neue Datensatz hat fehlerhafte num. Feldinhalte !
    ...und das kann ich in der S36-Umgebung mangels Quellcode nicht ändern !!!

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Beim Erstellen des Triggers per ADDPFTRG die Option ALWREPCHG auf *YES stellen, denn werden Pufferänderungen im Before-Trigger auch übernommen.

    Aber du hast schon die genaue interne Struktur?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Nov 2004
    Beiträge
    325
    Moin,


    das mit den /36 Daten kenne ich leider zur genüge. Damit kämpfen wir auch, die Dateien enthalten alles was so eine /36 Datei enthalten kann:



    • Satzarten
    • undefiniertes, von dem keiner mehr was weiss
    • Datumsangaben in allen Variationen und (Un-) Gültigkeiten
    • blanks in gepackten Felder und gezonten Feldern usw.


    Sollte dir die genaue interne Struktur bekannt sein, dann versuche folgendes: Triggerprogramm anklemmen, das Programm mach dann eine Korrektur mit SQL update /36 Datei set substr(Feld , von , länge) = : Neuer Wert.


    Ist sicherlich nicht schön, aber funzt gut.

    mfg

    DKSPROFI

  8. #8
    Registriert seit
    Jan 2003
    Beiträge
    290
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Beim Erstellen des Triggers per ADDPFTRG die Option ALWREPCHG auf *YES stellen, denn werden Pufferänderungen im Before-Trigger auch übernommen.

    Aber du hast schon die genaue interne Struktur?
    Danke für die Info.
    Ja, die Struktur der Dateien habe ich.

  9. #9
    Registriert seit
    Jan 2003
    Beiträge
    290
    Zitat Zitat von DKSPROFI Beitrag anzeigen
    Moin,


    das mit den /36 Daten kenne ich leider zur genüge. Damit kämpfen wir auch, die Dateien enthalten alles was so eine /36 Datei enthalten kann:



    • Satzarten
    • undefiniertes, von dem keiner mehr was weiss
    • Datumsangaben in allen Variationen und (Un-) Gültigkeiten
    • blanks in gepackten Felder und gezonten Feldern usw.


    Sollte dir die genaue interne Struktur bekannt sein, dann versuche folgendes: Triggerprogramm anklemmen, das Programm mach dann eine Korrektur mit SQL update /36 Datei set substr(Feld , von , länge) = : Neuer Wert.


    Ist sicherlich nicht schön, aber funzt gut.

    mfg

    DKSPROFI
    Die Strukturen der Dateien habe ich.
    Ich schiebe den Satz in eine DS ohne Felder und prüfe dann im von-bis Bereich der num. Felder den Inhalt auf x'40' oder auch x'00'.
    Wenn fehlerhaft, korrigiere ich den von-bis Bereich und schiebe die DS ohne Felder in die DS für die extern beschriebene Datei, bevor ich den Satz schreibe.

    Vg.

  10. #10
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Wenn du das im Trigger machst, kannst du dir die Schieberei ja sparen.
    Die Triggerinfo übergibt dir eine relative Adresse zum Puffer.
    Somit kannst du folgendes tun:

    dcl-s basBI pointer;
    dcl-s basAI pointer;

    dcl-ds BI based(basBI);
    end-ds;

    dcl-ds AI based(basAI);
    end-ds;

    basBI = %addr(Triggerinfo) + Triggerinfo.OrigOffset;
    basAI = %addr(Triggerinfo) + Triggerinfo.NewOffset;

    Somit kannst du auch mehrere Strukturen auf derselben Adresse basieren lassen:

    dcl-ds BIChar based(basBI);
    end-ds;

    dcl-ds AIChar based(basAI);
    end-ds;

    D.h., in AIChar prüfst du, und in AI schreibst du.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #11
    Registriert seit
    Jan 2003
    Beiträge
    290
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Wenn du das im Trigger machst, kannst du dir die Schieberei ja sparen.
    Die Triggerinfo übergibt dir eine relative Adresse zum Puffer.
    Somit kannst du folgendes tun:

    dcl-s basBI pointer;
    dcl-s basAI pointer;

    dcl-ds BI based(basBI);
    end-ds;

    dcl-ds AI based(basAI);
    end-ds;

    basBI = %addr(Triggerinfo) + Triggerinfo.OrigOffset;
    basAI = %addr(Triggerinfo) + Triggerinfo.NewOffset;

    Somit kannst du auch mehrere Strukturen auf derselben Adresse basieren lassen:

    dcl-ds BIChar based(basBI);
    end-ds;

    dcl-ds AIChar based(basAI);
    end-ds;

    D.h., in AIChar prüfst du, und in AI schreibst du.

    Cool :=) Danke. Vg.

Similar Threads

  1. Doktorspiele oder wie erstelle ich ein SQL-Trigger
    By KingofKning in forum NEWSboard Programmierung
    Antworten: 2
    Letzter Beitrag: 17-07-20, 13:03
  2. *.csv oder *.txt mit einer Datensatz-Größe von mehr als 32 MB
    By votch in forum NEWSboard Programmierung
    Antworten: 17
    Letzter Beitrag: 03-02-20, 13:42
  3. SQL Update - Nur den ersten Satz ändern
    By svente in forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 22-08-18, 17:34
  4. Trigger sperrt Datensatz
    By Peet in forum NEWSboard Programmierung
    Antworten: 5
    Letzter Beitrag: 31-05-17, 11:41
  5. Update (rewrite und/oder write) wird nicht aktiv
    By woy in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 26-03-15, 09:49

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •