Embedded SQL und Stored Procedure

[B.Hauser]

Arbeitest du mit Commit/Rollback ?
Nach einem Commit/Rollback ist ein vorbereitetes Statement wieder weg, du musst also erneut einen Prepare ausführen.

Prepared Statements bleiben über Commit-Grenzen nicht erhalten.

Bist Du sicher?
Eigentlich sollten beim Commit oder Rollback lediglich die Cursor geschlossen werden (sofern sie nicht mit WITH HOLD definiert sind).
Beim nächsten Aufruf (mit den gleichen Werten) sollte ein OPEN (ggf. mit anderen Parameter-Marker-Werten) genügen.

Birgitta

[Fuerchau]

Laut Beschreibung des SQL-Fehlers.

[BenderD]

... hier muss man fein differenzieren:
bei SQLCLI (und allem, was das benutzt) werden die prepares mit freigegeben.
Datenbanktreiber, die auf meist auf SQLCLI aufsetzen, könnten das aber wieder toppen (indem sie aus dem Commit implizit einen Commit hold machen).

Bei embedded SQL würde ich das für einen Bug halten, rate aber von Stresstests ab.

Die hold klauseln bei declare cursor, commit etc sind DB2 spezifische Erweiterungen, sollte man sich eigentlich eher abgewöhnen. Wobei ich beim Thema ANSI SQL immer mehr Illusionen verliere, je mehr ich mich damit beschäftige und bei der Arbeit an meiner DB2/400 JDBC Bridge für RPG und Co. fällt da einiges an, umso mehr kräuseln meine Nackenhaare, bei DB2/400, aber auch bei Oracle und manchen JDBC Treibern...

D*B

Bist Du sicher?
Eigentlich sollten beim Commit oder Rollback lediglich die Cursor geschlossen werden (sofern sie nicht mit WITH HOLD definiert sind).
Beim nächsten Aufruf (mit den gleichen Werten) sollte ein OPEN (ggf. mit anderen Parameter-Marker-Werten) genügen.

Birgitta

[andreaspr@aon.at]

Die hold klauseln bei declare cursor, commit etc sind DB2 spezifische Erweiterungen, sollte man sich eigentlich eher abgewöhnen. Wobei ich beim Thema ANSI SQL immer mehr Illusionen verliere, je mehr ich mich damit beschäftige und bei der Arbeit an meiner DB2/400 JDBC Bridge für RPG und Co. fällt da einiges an, umso mehr kräuseln meine Nackenhaare, bei DB2/400, aber auch bei Oracle und manchen JDBC Treibern...

Ich habe mal ein Buch gelesen der mit einen passenden Satz beginnt:
Entscheidet man so offen zu entwickeln, dass das gleiche Konzept auf verschiedenen Plattformen gleich laufen soll, so verzichtet man auf viele Vorzüge die das bestehende System mit sich bringt.

[BenderD]

... gute Konzepte sind immer einfach und lassen sich dann ohne nennenswerte Probleme auf (fast) allen Plattformen abbilden. Das Buch würde ich in die Rubrik "empfehlenswerte Ausreden" einsortieren.

D*B

Ich habe mal ein Buch gelesen der mit einen passenden Satz beginnt:
Entscheidet man so offen zu entwickeln, dass das gleiche Konzept auf verschiedenen Plattformen gleich laufen soll, so verzichtet man auf viele Vorzüge die das bestehende System mit sich bringt.

[Fuerchau]

@Birgitta
Man muss unterscheiden zwischen einem Declare Cursor, der in das interne SQLPKG eingebettet ist und einem expliziten Prepare eines Statements.
Das interne Statement wird automatisch prepared, sobald man es benötigt und nicht existiert. Deshalb sind Commit-Grenzen da nicht relevant.
Offene Cursor unterliegen da wiederum den Options-Einstellungen und dem jeweligen Commit ggf. with hold.

Mache ich einen expliziten Prepare eines Statements, muss ich das ggf. wiederholen.
Insbesonders in Procedure/Function, wo ich ja keinen eigenen Commit/Rollback machen darf, kann ich mich auf die Existenz eines Statements ggf. nicht verlassen.
Allerdings schadet ein erneuter Prepare auch nicht, falls das Statement schon existiert. Der wird einfach mit SQL-Fehler abgewiesen.

[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.