View Full Version : Resultset aus Stored Prozedure in SQLRPGLE
Hallo zusammen,
ist es möglich eine SQL Stored Procedure aus einem SQLRPGLE aufzurufen und das Resultset zu empfangen um dieses zu verarbeiten? vllt. hat jmd auch ein Bsp!?
Danke für eure Antworten.
SQLRPGLE kann das nicht, allenfalls SQL CLI APIs, aber wirklich Spass machen würde mir das nicht.
D*B
IBM Redbooks | Stored Procedures, Triggers, and User-Defined Functions on DB2 Universal Database for iSeries (http://www.redbooks.ibm.com/abstracts/sg246503.html)
Retrieve an SQL Result Set with RPG | System iNetwork (http://systeminetwork.com/article/retrieve-sql-result-set-rpg)
Hallo zusammen,
ist es möglich eine SQL Stored Procedure aus einem SQLRPGLE aufzurufen und das Resultset zu empfangen um dieses zu verarbeiten? vllt. hat jmd auch ein Bsp!?
Danke für eure Antworten.
hm dann werde ich mir das Ergebnis wohl lieber in einer Zwischentabelle ausgeben lassen...
Kann man um eine Prozedur eine weitere Prozedur herumbauen, die das Resultset der ersten Proc. in eine Tabelle ausgibt?
Ich möchte die erste Prozedur nämlich nur ungern ändern da sie mir an zu vielen Stellen aufgerufen wird :)
im Grunde bleiben 3 Optionen:
- die CLI Variante (wie in dem Artikel)
- Procedure um Procedure geht auch (eine SQL Procedure kann durchaus einen SQL Call machen und auch ein Resultset verarbeiten
- UDTF (User defined Table Function) müsste auch gehen, das ist auch ein SQL Programm, das allerdings wie eine Tabelle verarbeitet wird
Die erste Variante hätte den Vorteil das sie Satzweise arbeitet, ist aber wohl in der Programmierung am aufwändigsten. Variante 2 und 3 arbeiten en Block, der erste Satz ist erst verfügbar wenn die ganze Tabelle erstellt wurde. Variante 2 und 3 sind im Programmieraufwand relativ niedrig. Was für Variante 3 spricht, ist dass die ganze Mimik dem aufrufenden Programm verborgen bleibt, das glaubt eine Datei zu verarbeiten.
D*B
hm dann werde ich mir das Ergebnis wohl lieber in einer Zwischentabelle ausgeben lassen...
Kann man um eine Prozedur eine weitere Prozedur herumbauen, die das Resultset der ersten Proc. in eine Tabelle ausgibt?
Ich möchte die erste Prozedur nämlich nur ungern ändern da sie mir an zu vielen Stellen aufgerufen wird :)
und wie kann ich eine Proc in einer Proc aufrufen?
DECLARE CSR_PROC1 INSENSITIVE SCROLL CURSOR WITHOUT RETURN FOR
CALL BIB/PROCNAME () ;
das geht nicht :(
.. editiert, siehe Folgebeitrag
Das Problem ist nicht der Proc Aufruf (die Procedure wird nicht deklariert, sondern simpel benutzt, wie eine Tabelle).
.. ich hatte da ein Beispiel mit nested stored Procedure und ResultSet im Hinterkopf; beim nachrecherchieren bin ich dann darauf gestoßen, dass die ResultSets da nur durchgereicht werden und nicht verarbeitet, sozusagen blind durchgereicht (mir dreht sich alles um). In DB2 werden die ResultSet Declarations über Locator gemacht, das wird aber von DB2/400 auch nicht unterstützt (soviel zu UDB), damit bleibt von meinen drei "Hoffnungsträgern" nur noch die CLI Variante (und auch die Temptable Variante kommt ohne dies nicht aus).
Ergänzend sei noch angemerkt: bisher ist mir noch kein Anwendungsbeispiel über den Weg gelaufen, das mich davon überzeugt hätte, dass ich das so machen sollte (da gab es immer bessere Alternativen), mein Kenntnisstand an dieser Stelle ist also rein akademisch und nicht von praktischem Einsatz in realen Applikationen untermauert! Falls dein Einsatzbeispiel eines sein sollte das belegt, dass dieser Weg Designvorteile hat, würde es mich interessieren was ihr damit macht.
D*B
und wie kann ich eine Proc in einer Proc aufrufen?
DECLARE CSR_PROC1 INSENSITIVE SCROLL CURSOR WITHOUT RETURN FOR
CALL BIB/PROCNAME () ;
das geht nicht :(
ich habe ne Menge SQL-Stored-Procedures programmiert, und nach einigen Erfahrungen dann sehr gern in SQL programmiert. Gerade wenns komplizierter wird, kann man die ja sehr gut strukturieren, sehr übersichtlich. Man kann sich eine ganze Bibliothek von SQL-Funktions und -Procedures anlegen, und je weiter man kommt, desto leichter wird das Leben (Programmieren).
Von daher frage ich mich oft, ob man überhaupt noch RPG oder COBOL braucht, und schlage vor, die Stored-Procedure nicht nur als Krücke zu benutzen, sondern als mächtiges Tool im Rahmen eines Redesigns.
Im Endeffekt können dann z.B. moderne Windows-Clients, die mit C++ oder C# erstellt werden, mit den SQL-Stored-Procedures auf der i-Series kooperieren. Dabei wäre Java mal nicht die 1.Wahl.