embedded SQL Cursor with Hold und Commit/Rollback

[Fuerchau]

Ja aber: Activation-Groups erstellen auch getrennte Transaktionen. Das aufgerufene Programm muss also seinen eigenen Commit/Rollback durchführen. Wenn es das nämlich vergisst, war alles für die Katz'.

Allerdings musst du da etwas durcheinander bringen.
Ein Cursor "with Hold" wird beim Rollback eben nicht zurückkgesetzt.

https://www.google.com/search?client...rsor+with+hold

[steffenboehme]

Danke für die Infos.
Der Cursor "with hold" wird bei Rollback geschlossen und das ist mein Problem, da er offen bleiben muß für die weiteren Verarbeitungen.
Wenn das nur mit getrennten Aktivierungsgruppen geht, haben wir in unserer Anwendung was zu tun, da wir immer dftactgrp(*no) actgrp(*caller) in den CTL-OPT implemetiert haben.
Oder gibts da noch was anderes?

[B.Hauser]

Setz beim SQL Commit und Rollback WORK HOLD dahinter:

Exec SQL Commit Work Hold;

oder versuch statt des SQL Commit und Rollback den RPG Commit und Rolbk zu verwenden

Birgitta

[Fuerchau]

Nur mal ne blöde Frage:
Bist du sicher, dass der Cursor in der Programmkette eindeutig ist?
Wenn der selbe Cursorname wieder verwendet wird, scheitert der Open aber der Close nicht.
Im Debugmodus solltes du da Hinweise finden können.

[B.Hauser]

Ein Cursor-Name muss eindeutig innerhalb einer Quelle/Moduls sein! Außerhalb des Moduls kann der gleiche Cursor-Name wieder verwendet werden, unabhängig davon ob das Programm/Modul/Prozedur in der gleichen Programm-Kette aufgerufen wird.

[BenderD]

... das mit der ACTGRP ist eh keine gute Idee. Man hat einen Commit Master, das ist der, der die Transaktion steuert und alle slaves sind *CALLER. Das HOLD beim Cursor wirkt nur beim Commit, beim Rollback muss zusätzlich nochmals hold angegeben werden. Das ist zwar kein ANSI, sondern DB2 Erweiterung, sollte aber funzen (sonst ist mit den PTFs was faul).

D*B