embeddet SQL, Lib variable setzen

[malzusrex]

Hallo Dietlinde,

mache vorher einfach einen OVRDBF

dcl-pr System int(10) extproc('system');
 *n pointer value options(*string);     
end-pr;                                 

System( 'ovrdbf Datei ' + %Trim(MyLib) +'/SAPASOP' );   
Exex SQL
  SET :SZAZ =(SELECT MAX(#XKEY#) FROM DATEI WHERE #INKEY# > 0); 

Gruß
Ronald

[Fuerchau]

Das ist eine der schlechtesten Lösungen;-) da sie nicht SQL-Konform ist.
OVRDBF's sollte (und muss) man in SQL vermeiden, da eine Tabelle ja durchaus geöffnet bleibt und mit dieser weitergearbeitet wird auch wenn man den OVRDBF wieder löscht.
Das selbe gilt ebenso für CHGLIBL zur Laufzeit.

Der richtige Weg wäre ein dynamischer SQL per "Execute Statement".

[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