Embedded SQL und Stored Procedure

[andreaspr@aon.at]

Insbesonders in Procedure/Function, wo ich ja keinen eigenen Commit/Rollback machen darf, kann ich mich auf die Existenz eines Statements ggf. nicht verlassen.

Ich bin mir jetzt nicht sicher wie es in früheren OS-Versionen war, aber ab 6.1 können auch innerhalb von Procedures Commit/Rollback abgesetzt werden. Ist allerdings auch etwas aufwendiger. (Aktivierungsgruppen, Rollback-Punkte setzen usw.)

[Fuerchau]

Das ist das, was andere DB's schon lange geschachtelte Transaktionen nennt.
Ich kann damit innherhalb der Prozedur eine eigene Transaktion definieren, die jedoch die übergeordnete Transaktion nicht berühren darf.
Ein Commit/Rollback der Haupttransaktion wird sowieso abgewiesen.

[andreaspr@aon.at]

Ich weis dieses Thema ist schon länger her, allerdings hatte ich erst jetzt Zeit meine Vermutung zu testen, sodass ich nicht irgendwelche unbelegten Behauptungen aufstelle.

Also für alle dies interessiert ... ich kann eine Procedure so definieren, dass wenn ich dort ein Rollback absetze, nicht nur zB die Inserts innerhalb der Procedure rückgängig macht, sondern auch die änderung vom aufgerufenen Programm.
Genauso kann auch ein Rollback im Programm nach dem Aufruf der SP abgesetzt werden und auch die Änderungen der SP werden rückgängig gemacht.
Ist also alles nur eine Sache wie es definiert und eingesetzt wird. Und das gibt schon mindestens ab 5.4

[BenderD]

... ja, leider kann man solchen Unfug treiben. Commit und Rollback Operationen (nicht zu verwechseln mit SAVEPOINT) wirken immer auf die Connection (bei lokalem SQL und ILE = ACTGRP oder JOB, bei OPM = JOB).
Setzt man es richtig ein (das ist keine Geschmacksache!!!), dann kontrolliert ein Commit Master alle Änderungen der Programme, die er aufruft und nie umgekehrt-

D*B

Also für alle dies interessiert ... ich kann eine Procedure so definieren, dass wenn ich dort ein Rollback absetze, nicht nur zB die Inserts innerhalb der Procedure rückgängig macht, sondern auch die änderung vom aufgerufenen Programm.

[andreaspr@aon.at]

... ja, leider kann man solchen Unfug treiben. Commit und Rollback Operationen (nicht zu verwechseln mit SAVEPOINT) wirken immer auf die Connection (bei lokalem SQL und ILE = ACTGRP oder JOB, bei OPM = JOB).
Setzt man es richtig ein (das ist keine Geschmacksache!!!), dann kontrolliert ein Commit Master alle Änderungen der Programme, die er aufruft und nie umgekehrt-

D*B

Da hast du Recht. Es ist sicher besser, wenn ich aus einer SP einen SQLSTT zurückgebe und im Haupt-pgm entscheide was zu tun ist.
Trotzdem wollte ich dieses Missverständnis aufklären, auch wenn das den einen oder anderen nicht so schmeckt

[Fuerchau]

Ein Rollback, von dem der Caller nichts weiß führt u.U. zum Endlosprogramm.
Der Rollback (ohne spezielle Angabe) setzt nämlich auch die Lesecursor wieder zurück, so dass das aufrufende Programm die selben Daten noch einmal liest und im Zweifel zum selben Rollback führt.