View Full Version : Embedded SQL und Stored Procedure
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
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
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.
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
Laut Beschreibung des SQL-Fehlers.
... 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
26-08-10, 08:45
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.
... 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.
@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
26-08-10, 11:14
... 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
Nö find ich nicht. Dieses Thema wurde schon oft diskutiert und es ist kein geheimnis, dass Abstriche gezogen werden müssen wenn man sooo offen sein will. (!!!Bezogen auf Programmier- u. Datenbanktechniken!!!) Bin mir sogar ziemlich sicher, dass du das selbst mal gepostet hast ;)