dynamisches SQL mit Clob möglich?

[Fuerchau]

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.

[BenderD]

... 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

[Fuerchau]

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.

[BenderD]

... 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

[Fuerchau]

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.

[BenderD]

... da hätte ich eher SQL CLI genommen (Geschmacksache sagte der Affe und biss in die Seife)

[Fuerchau]

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.