View Full Version : dynamisches SQL mit Clob möglich?
"Execute ... Using" gilt leider nur für Parametermarker.
MyStmt = "Select ... where f1=?";
prepare ...
execute ... using MyVar;
Um Ergebnisse zu erhalten geht das nur per Descriptor (SQLDA mit SQLVAR-Array).
Wer sich das zutraut kann das verwenden. Dies ist dann vielleicht schneller als Open/Fetch/Close.
... den select into kann man auch mit einer SQLDA nicht dynamisch preparen, aber values into kann man dynamisch preparen, auch ohne SQLDA. Performance relevant ist das so oder so nicht, da der Declare cursor eine Compiletime Geschichte ist, die Musik spielt beim prepare und beim open/fetch versus execute using könnte die typisierte variante (mit SQLDA) sogar im Vorteil sein - allerdings legt das alles im Bereich unterhalb der Messbarkeitsgrenze.
D*B
Danke für die Tips. Mal wieder was gelernt...
Ist schon seltsam, dass der "Select Into" eigentlich dem "Value Into" vollkommen entspricht da beide nur eine einzelne Zeile zurückgeben dürfen.
Allerdings vermisse ich beim "Values Into" die Beschreibung, wie das mit einem Prepared Statement gehen soll.
Entweder ich prepare den "Values..." mit anschließendem "Execute into", wobei der Execute ja bei INTO nur eine SQLDA erlaubt oder ich kann beim "Values" statt eines Ausdruckes auch einen Statementnamen angeben. Das ist so aber nicht dokumentiert.
... wie sonst auch:
D*B CRTSQLRPGI TSTVALUES
D*B+ OBJTYPE(*MODULE)
D*B+ DBGVIEW(*SOURCE)
D*B CRTPGM TSTVALUES
D*B+ ACTGRP(TSTVALUES)
d maxname s 30
d halstring s 128
halstring = 'values (select max(vorname) from covelenz) '
+ 'into ?';
exec sql
prepare s1 from :halstring;
exec sql
execute s1 using :maxname;
dsply maxname;
exec sql commit;
return;
das mit values und select into verstehe ich auch nicht, wahrscheinlich hat der erste Versuch das zu implementieren zu einem Bug im Parser beim parsen des Select geführt und dann hat man...
oder das war wieder so eine Kantinenwette, wo die SQL Crew mit der RPG Crew gewettet hat, dass man auch eine unnötige Anweisung im SQL unterkriegt...
D*B
Ok, aus der Doku für Execute ging nicht eindeutig hervor, dass "using" auch für Ausgabeparameter gilt (z.B. für dynamische SQL-Prozeduraufrufe interessant).
Den komplexen "execute ... into Descriptor" benötigt man dann ja jetzt nicht mehr.
... ich habe noch nie SQL Deskriptoren verwendet, den einzigen Fall, den ich sehe, ist: Wenn man den Tabellennamen, bzw. die Parameterliste oder die Struktur eines ResultSets erst zur Laufzeit kennt und bis dahin flexibel halten will (in anderen Worten: Mit Kanonen auf Spatzen schießen will, Dinge unnötig verkomplizieren oder zeigen will, dass man unverständliche Programme schreiben kann).
Die Datenbank baut einem eh# für die Rückgaben eine SQLDA, die mit den Daten zurückkommt.
D*B
Ich habe in V4R3 einen variablen SQLCPY (als CMD) entwickelt, der heute auf V7R1 immer noch funktioniert und auch sehr häufig eingesetzt wird.
Hier muss mit SQLDA's gearbeitet werden da weder Tabellen noch Felder zur Compilezeit bekannt sind.
Da haben es dynamische Sprachen wie Java/VB/.NET... natürlich erheblich einfacher.
In einer normalen Anwendung habe ich SQLDA's auch noch nie benötigt.
... da hätte ich eher SQL CLI genommen (Geschmacksache sagte der Affe und biss in die Seife)
Da dies nun schon eine Weile hier ist (ca. 1999/2000) war mir CLI auf der AS/400 und C-Aufrufe aus COBOL noch unbekannt und RPG mache ich erst seit ca. 2002.
M.a.W.: der SQLCPY ist komplett in COBOL.