SQL UPDATE und COMMIT im SQLRPGLE

[harkne]

Was verstehst Du unter BULK-update. Mehrer Sätze? mehrere 1000 Sätze, mehrere Millionen Sätze. Grundsätzlich ist das egal, denn jeder der das Programm verwendet muss wissen was er macht. Deshalb kann er ja sagen mit oder ohne COMMIT. Und was ihr mit Eurer Commit-Grenze meint bin ich mir auch nicht sicher. Was soll das sein? Das ich keinen ENDCMTCTL mache wenn ich noch offene COMMITs habe? oder das ich erst einen COMMIT ausführe wenn ich den Soll und den Haben-Satz geschrieben habe. An dieser Stelle geht es einfach darum, dass wir UPDATES in einer Tabelle ablegen können die nacheinander ausgeführt werden. Die Tabelle hat einen Schlüssel Wenn jetzt jemand das Programm aufruft mit Schlüssel KEY1, werden alle SQLs ausgeführt die unter dem Schlüssel KEY1 augeführt sind. z.B. KEY1 UPDATE DATEI SET STATUS = 'X' WHERE PARTGROUP = 'Y' und dann noch KEY1 UPDATE DATEI SET STATUS = 'V' WHERE PARTGROUP = 'A'. Jetzt entscheidet der der das Programm aufruft ob es ein Problem ist wenn SQL1 ausgeführt wird und SQL2 abbricht. Wenn das kein Problem ist, braucht er meiner Ansicht nach auch keine Commit-Steuerung. Das kann aber nicht ich entscheiden, sondern muss der entscheiden der die SQLs in der Tabelle anlegt und aus seinem Programm aus dann das Programm hier aufruft mit Schlüsselwert um die SQLs auszuführen. Wie gesagt, ich versuche die COMMIT-Steuerung schon immer zu vermeiden wenn ich sie nicht brauche. Und da unterscheide ich nicht zwischen BULK oder gutem Stil oder sonst was. Brauche ich die COMMIT-Steuerung Ja oder Nein. Und es gibt oft die Antwort NEIN.

[BenderD]

@Bulk update: genau das was ihr hier macht, ist ein typischer Bulk update!Unter commit werden hier alle geänderten Sätze gesperrt, da sind Abbrüche geradezu vorprogrammiert und deadlock Situationen vorprogrammiert.

@Commit Grenze: Unter commit beginnt eine Transaktion mit der ersten Sperre und endet mit dem commit/rollback. Innerhalb der Transaktion sind bestimmte Operationen für den Job nicht durchführbar: ENDCMTCTL, set transaction, disconnect, die gehen nur an einer commit Grenze := außerhalb einer Transaktion.

@commit nein: ohne commit kann z.B. zwischen einem select into und nachfolgendem update von anderen Jobs der Inhalt verändert werden. Commit Steuerung aus Unkenntnis zu vermeiden erzeugt Fehlersituationen, die Daten beschädigen können. Alles was mehr als einen Satz verändert (Umbuchungen, Fortschreibung von Summen etc. (und was tut das nicht) gehört in Transaktionen mit commit geklammert - alles andere ist Murks oder viel komplizierter zu programmieren.

D*B

[harkne]

Ich habe jetzt an die SQL-Statements WITH NC ran gemacht wenn keine Commit-Steuerung nötig ist, das ist übersichtlich und funktioniert.

Also für alle die es interssiert

CL hat STRCMTCTL
RPG hat
SET OPTION COMMIT=*CHG
Wenn kein Commit erforderlich ist hänge ich an die SQL-Statements WITH NC dran.
Im CL mache ich dann den COMMIT bei gewünschter Commit-Steuerung
Hinter dem Call ans RPG noch MONMSG und ROLLBACK bei gewünschter Commit-Steuerung
Am Ende wenn das Programm den STRCMTCTL ausgeführt hat macht er auch den ENDCMTCTL