embeddet SQL, Lib variable setzen

[Dschainers]

z.B.

d sqlstm s 1024a varying
d wrkfile s 20a inz('QTEMP/TESTFILE')
/Free
sqlstm = 'CREATE Table ' + %trim(wrkfile) +
' as +
(select * from test) +
with data ';

/End-Free
c/exec sql
c+ execute immediate :sqlstm
c/end-exec
c move *on *inlr

[dibe]

z.B.

d sqlstm s 1024a varying
d wrkfile s 20a inz('QTEMP/TESTFILE')
/Free
sqlstm = 'CREATE Table ' + %trim(wrkfile) +
' as +
(select * from test) +
with data ';

/End-Free
c/exec sql
c+ execute immediate :sqlstm
c/end-exec
c move *on *inlr

Und wo landet das Ergebnis?

[Fuerchau]

Welches Ergebnis?
Dieses Ergebnis ist eine neue Tabelle!
Ich weiß auch nicht, was dies mit deiner Frage zu tun hat.

Deine Anfrage geht nur mit einem dynamischen Cursor (ohne Exec SQL):

D MyOpen S 1000 varying

MyOpen = 'Select blabla ....';
prepare statement from : MyOpen;
declare OpenCursor cursor for MyOpen;
open OpenCursor;
fetch OpenCursor into : MyVar;
close OpenCursor;

[Dschainers]

Ich wollte nur aufzeigen, wie man ein variables SQL Statement zusammenbaut.
Da dies anscheinend noch nicht bekannt war.

[BenderD]

Welches Ergebnis?
Dieses Ergebnis ist eine neue Tabelle!
Ich weiß auch nicht, was dies mit deiner Frage zu tun hat.

Deine Anfrage geht nur mit einem dynamischen Cursor (ohne Exec SQL):

D MyOpen S 1000 varying

MyOpen = 'Select blabla ....';
prepare statement from : MyOpen;
declare OpenCursor cursor for MyOpen;
open OpenCursor;
fetch OpenCursor into : MyVar;
close OpenCursor;

statement Name im declare und prepare müssen matchen, also:

exec sql declare OpenCursor cursor for MyOpen;
exec sql prepare MyOpen from : MyOpen;

D*B,

dem sich bei Datenbank und LIBL der Magen rumdreht. Besser wäre, Namimg *SQL und die Umgebung über das default Schema zu steuern.

[malzusrex]

z.B.

d sqlstm s 1024a varying
d wrkfile s 20a inz('QTEMP/TESTFILE')
/Free
sqlstm = 'CREATE Table ' + %trim(wrkfile) +
' as +
(select * from test) +
with data ';

/End-Free
c/exec sql
c+ execute immediate :sqlstm
c/end-exec
c move *on *inlr

genau das hatte ich bei mir mit dem SET gestestet. Und es hat bei mir nicht funktioniert. Deshalb bin ich auf dem OVRDBF gekommen

[Fuerchau]

Was soll den ein "Create Table" für eine Set-Anweisung zurückliefern?
Das wäre mir aber neu;-).

[AG1965_2]

Die Frage, wie man Werte aus einem dynamischen SQL herauskitzeln kann, wurde aber nicht beantwortet.

D #SQL            S           5000A   VARYING                  
 *                                                             
D #LIB            S             10A   INZ('QTEMP')             
D #FILE           S             10A   INZ('TEST')              
 *                                                             
D #Anz1           S             10P 0                          
                                                               
 /FREE                                                         
        #SQL = 'VALUES( +                                      
                  SELECT COUNT(*) FROM ' + %TRIMR(#LIB) + '/' +
                                           %TRIMR(#FILE) +     
                     ') +                                      
                INTO ?';                                       
                                                               
    EXEC SQL PREPARE Stmt1 FROM :#SQL;                         
                                                               
    EXEC SQL EXECUTE Stmt1 USING :#Anz1;                       
                                                               
 /END-FREE

von Scott Klement abgeschaut; z.B. hier noch komplexer:
https://www.ibm.com/developerworks/c...8-94cd018d1560

[Fuerchau]

Wenn du mein obiges (von Dieter korrigiertes) Beispiel anschaust, siehst du das sehr wohl.
Nur mit dem Unterschied, dass per Cursor Resultsets und mehr als 1 Wert übergeben werden können.
So verfahre ich z.B. bei embedded SQL via ArdGate um Daten aus Oracle oder SQL-Server direkt im Programm zu erhalten.

Scotts Beispiele aus dem Link beschränken sich da auf 1 Satz per Values, was einem "select blabla into .... from ..." entspricht.

[B.Hauser]

Scotts Beispiele aus dem Link beschränken sich da auf 1 Satz per Values, was einem "select blabla into .... from ..." entspricht.

Wenn ein SET-Statement in Verbindung mit einem SELECT-Statement ausgeführt wird, muss genau eine Zeile zurückkommen. Das war die Ausgangssituation!

Wenn man das Ganze dynamisch machen möchte bzw. muss (weil die Tabelle oder Bibliothek flexibel gehalten werden müssen), kann man entweder

• ein VALUES ... INTO Statement dynamisch zusammensetzen und dann mit PREPARE und EXECUTE ausführen, wie es AG1965_2 gezeigt hat oder
• Verwendet einen Cursor, d.h. man bildet das dynamische SELECT-Statement, konvertiert dieses in ein ausführbares SELECT-Statement (PREPARE). Das konvertierte SELECT-Statement wird dann in das DECLARE-Statement eingebunden und danach folgt der übliche Verlauf, d.h. der Cursor muss geöffnet werden (OPEN), der einzelne/erste Datensatz gelesen werden (FETCH) und dann muss der Cursor wieder geschlossen werden (CLOSE).

Weder SET noch SELECT ... INTO können in Verbindung mit dynamischem verwendet werden.

Die Frage ist nur, warum sollte man an dieser Stelle 5 SQL-Statements ausführen, wenn man stattdessen mit 2 Statements auskommen kann?
Nein, ich habe mich nicht verzählt, das SQL-Statement kann auch direkt im PREPARE zusammengesetzt werden!

Birgitta

[BenderD]

... das ist einfach zu beantworten:
values into ist kein SQL Standard, zudem ist die standard Version mit cursor im Fehlerfall einfacher zu behandeln - sprich defensiver. Das ist Dir aber vermutlich egal, Du empfiehlst ja auch naming *sys, commit(*none) und Datenschrank Verarbeitung nach LIBL - ich empfehle halt was anderes, lass doch jeden selbst entscheiden.

D*B

[andreaspr@aon.at]

Das ist Dir aber vermutlich egal, Du empfiehlst ja auch naming *sys, commit(*none) und Datenschrank Verarbeitung nach LIBL - ich empfehle halt was anderes, lass doch jeden selbst entscheiden.

Ist ja wieder einmal amüsant zu lesen.
Birgittas Empfehlungen basieren so gut wie immer auf den jeweiligen Anforderungen.
Und ja, wenn ein Unternehmen noch niergends Commit im Einsatz hat, dann empfehle ich nicht bei einer kleinen Anpassung dies gleich zu verwenden. Da gehört vorher ein überlegtes Design her (auch fürs Testen).

Genauso könnte man behaupten, dass Dieter empfiehlt alles bestehende weg zu schmeißen und neu zu entwickeln und das am besten mit einer "richtigen" DB und einer "richtigen" Programmiersprache.