SQL-Transaktionen auf AS400?

[B.Hauser]

Bei STRSQL musst du vorher einen STRCMTCTL absetzen sonst gehts da auch nicht.

Das stimmt nicht! SQL (interaktives oder auch embedded SQL) führen den STRCMTCTL (mit Unterlassungswerten aus), sofern mit Commitment Control gearbeitet wird und der STRCMTCTL in dem Job noch nicht ausgeführt wurde!

Dateien, die nicht aufgezeichnet werden, können beim Rollback auch nicht zurückgedreht werden.

Wird mit SQL und Commitment Control gearbeitet und wird die Datei nicht aufgezeichnet, führt SQL den Insert, Update oder Delete nicht durch, sondern bringt die Fehlermeldung:
MyTable in MyLib für Operation ungültig.

Wenn man nur eine Transaktionssicherheit gewährleisten will, kann man die Journal-Receiver so definieren, dass sie sobald sie abgehängt werden gelöscht werden. Ein Journal-Receiver bleibt solange geöffnet, bis die letzte angefangene Transaktion beendet wird.

Im interaktiven SQL (nach STRSQL) kannst Du Deine Session-Attribute mal mit F13 ändern, und zwar den Commitment-Level auf *ALL oder so setzen. Danach kannst Du sofort ROLLBACK und COMMIT ausprobieren. Anschließend bitte mal mit den Alternativen zu *ALL beschäftigen, denn *ALL blockiert geänderte Sätze, bis der aktuelle COMMIT-Zyklus beendet wird (ROLLBACK oder COMMIT).

Ich würde nicht gerade mit dem höchsten Commitment-Level *ALL anfangen, bei dem ich mir alles dicht mache, sondern mit dem niedersten UR (uncommitted read) oder *CHG. Ein unter Commit gesperrter Satz kann nur durch den nächsten Commit oder Rollback im gleichen Job wieder freigegeben werden, z.B. der RPG-Befehl UNLOCK oder die Erweiterung (N) ziehen nicht!

... "Schmalspur"-Journaling mit Gewährleistung der Transaktionssicherheit sollte man auf alle Fälle fahren.

Birgitta

[BenderD]

... Commit Level *ALL ist keineswegs die höchste Sperrstufe, sondern entspricht in ANSI Sprache dem repeatable read; diese Sperrrstufe ist in Programmen bequem für updates ohne Verwendung eines Cursors, Vorsicht ist angebracht bei Konstrukten wie select max(KundeId), das könnte die ganze Tabelle sperren.

Für interaktives SQL kommen in erster Linie in Betracht:
*CHG (entspricht read uncommited) zur Absicherung von Bulk updates
*CS (entspricht read commited) hiermit lassen sich konsistente Sichten während der Verarbeitung sicherstellen (allerdings nur, wenn die Anwendungen Commit verwenden, tut sie das nicht geht sowas nur im Batch)

BTW: der SQL Standard fordert serializable als default, was im DB2/400 so lausig implementiert ist, dass das mit RLA garnicht verwendbar ist!

D*B

Ich würde nicht gerade mit dem höchsten Commitment-Level *ALL anfangen, bei dem ich mir alles dicht mache, sondern mit dem niedersten UR (uncommitted read) oder *CHG. Ein unter Commit gesperrter Satz kann nur durch den nächsten Commit oder Rollback im gleichen Job wieder freigegeben werden, z.B. der RPG-Befehl UNLOCK oder die Erweiterung (N) ziehen nicht!

... "Schmalspur"-Journaling mit Gewährleistung der Transaktionssicherheit sollte man auf alle Fälle fahren.

Birgitta