View Full Version : SQL Procedure mit SQL-Befehl als Parameter
Hallo zusammen,
wie kann ich in einer SQL-Procedure den als Parameter übergebenen fertigen SQL-Befehl in
"DECLARE C1 CURSOR FOR" einsetzen bzw. nutzen ????
Beispiel wie es nicht geht :=(
CREATE OR REPLACE PROCEDURE data/kundesqp1
( IN PRSQLCMD CHAR(2048),
INOUT PRRETURN CHAR(1)
)
RESULT SET 1
LANGUAGE SQL
BEGIN
DECLARE C1 CURSOR FOR PRSQLCMD;
OPEN C1;
SET RESULT SETS CURSOR C1;
END
Irgendwie stehe ich da auf dem Schlauch...
Danke vorab !
Die SQL-Anweisung heißt "prepare statement...".
prepare statementname from variable
declare cursor name for statementname
Danke !
Manchmal steht man echt auf dem Schlauch...
Also wie im SQLRPG, nur prepare nach dem declare !!!...ich habe es im SQLRPG immer anderes herum ?!
...ich bin auch der Meinung ich hätte das schon mal gemacht...finde es aber nicht mehr...
Jetzt habe ich das eingebaut...und läuft :=)
Für alle, denen das ggf. auch mal passiert...hier der Code....
CREATE OR REPLACE PROCEDURE data/kundesqp1
( IN PRSQLCMD CHAR(2048),
INOUT PRRETURN CHAR(1)
)
LANGUAGE SQL
RESULT SET 1
SET OPTION COMMIT=*NONE, DATFMT=*EUR
BEGIN
DECLARE C1 CURSOR FOR S1;
PREPARE S1 FROM PRSQLCMD;
OPEN C1;
SET RESULT SETS CURSOR C1;
END
Danke nochmals !!!
Wofür denn eigentlich diesen Umweg?
Die Reihenfolge Declare/Prepare ist letztlich egal, da ja ein Declare nur eine Compiler-Anweisung ist.
Entscheidend ist, dass zum Zeitpunkt des tatsächlichen Zugrffes alles da sein muss.
Nachteil dieses Vorgehens:
Der Cursor C1 gilt für die gesamte Verbindung/Sitzung.
Solange der Cursor nicht geschlossen ist, kannst du kein neues Resultset anfordern!
Dies sei zu bedenken.
Zu bemerken ist das manchmal bei embedded SQL, dass ggf. bei einem Absturz des Programmes, Cursor nicht geöffnet werden können da sie noch offen sind.
Für Übungszwecke ganz i.O.
Wofür denn eigentlich diesen Umweg?
Die Reihenfolge Declare/Prepare ist letztlich egal, da ja ein Declare nur eine Compiler-Anweisung ist.
Entscheidend ist, dass zum Zeitpunkt des tatsächlichen Zugrffes alles da sein muss.
Nachteil dieses Vorgehens:
Der Cursor C1 gilt für die gesamte Verbindung/Sitzung.
Solange der Cursor nicht geschlossen ist, kannst du kein neues Resultset anfordern!
Dies sei zu bedenken.
Zu bemerken ist das manchmal bei embedded SQL, dass ggf. bei einem Absturz des Programmes, Cursor nicht geöffnet werden können da sie noch offen sind.
Für Übungszwecke ganz i.O.
Hallo,
die Reihenfolge war in der Procedure nicht egal, da ein Fehler beim create ausgegeben wurde.
Der Cursor soll ja für die gesamte Sitzung gelten, das war das Ziel dieses Test's.
Die Ergebnisse sind zufriedenstellend.
Danke und Gruß
Trotzdem hast du meine Frage nicht beantwortet:
Warum eine Prozedur und nicht direkt im Code?
Die Einschränkungen sind da schon nicht zu verachten, ins besonders wenn man an die Verwendung per ODBC/JDBC denken will.
Trotzdem hast du meine Frage nicht beantwortet:
Warum eine Prozedur und nicht direkt im Code?
Die Einschränkungen sind da schon nicht zu verachten, ins besonders wenn man an die Verwendung per ODBC/JDBC denken will.
Es ging um einen Test aus Net.Data heraus, teilweise "pur Net.Data", teilweise mit RPG.
Vg.
Warum auch neue Funktionen nutzen, wenn das properitäre Net.Data auch noch geht;-).
Warum auch neue Funktionen nutzen, wenn das properitäre Net.Data auch noch geht;-).
Ich mag das Geschwätz über Net.Data nicht, im Besonderen wenn man keine Erfahrung hat, und damit meine ich nicht "mal etwas mit gemacht" :=)
Große Projekte sind damit easy zu realisieren, das ist dann allerdings etwas anderes als z.B. bei Shell in Dortmund.
Und von "eingeschränkt" im Sinne von "properitär" kann überhaupt keine Rede sein !