Embedded SQL und Stored Procedure

[KM]

Hallo,

ich habe ein SQLRPG-Programm, in dem ich ein einfaches Select-Statement mit PREPARE vorbereite. Für dieses SQLRPG-Programm habe ich eine Stored Procedure erstellt. Wenn ich nun diese SP von einem Java-Client aus aufrufe, funktioniert es ohne Probleme und ich erhalte das gewünschte Ergebnis. Wenn ich es aber von PHP aus aufrufe, erhalte ich beim OPEN CURSOR immer den SQLCODE -514. Der SP werden in beiden Fällen dieselben Parameter übergeben. Das SQL-Statement ist in beiden Fällen absolut identisch. Ich hab das mit protokolliert. Nur warum erhalte ich bei PHP den SQLCODE -514 ???

Gruß,
KM

[KM]

Das Problem ist inzwischen gelöst. Der Benutzer, der die SP von PHP aufgerufen hat, hatte in seiner *LIBL nicht die betreffende Bibliothek. Wenn ich sie beim SELECT explizit angebe, funktioniert's.

Gruß,
KM

[Fuerchau]

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.

Ggf. ist Autocommit in der Verbindung gesetzt (meistens der Default).

Stelle in deinem Programm also sicher, dass der Prepare unmittelbar vor dem Execute ausgeführt wird und sich somit im selben Commit-Zyklus befindet.

[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