View Full Version : Dynamisches SQL in einem CL erstellen
RUNSQL gibt es auch kostenlos unter: RUNSQL (http://www.neuhauser.de/produkte/dateibefehle/runsql/index.html)
Worum geht's in diesem Thema eigentlich? Ist das Problem inzwischen vielleicht schon behoben?
Es gibt da noch einen kleinen Trick.
QMQRY interpretiert den SQL erst nachdem die Variablen gefüllt sind.
Der Inhalt jeder Variable kann bis zu 55 Zeichen lang sein.
Nun kann man also einfach einen QMQRY erstellen:
&V1&V2&V3&V4&V5
Per CLP kann der SQL nun in einer Variablen zusammengebaut werden.
Per "
STRQMQRY ... SETVAR((&V1 (%SST(&MYCLVAR 1 55)) (&V2 (%SST(&MYCLVAR 56 55)) ....)
kann dann jeder beliebige SQL übergeben werden.
(...)
Da gibt's aber ein Problem (arbeite unter V5R4)!
Es werden alle Variablenwerte, die ich dem SETVAR übergebe, getrimmt.
Trifft man zwischen zwei %SST, also z. B. auf Position 55, genau vor oder hinter ein Blank, so wird dieses Blank in der QMQRY-Verknüpfung &V1&V2&V3.... nicht wieder eingefügt.
Sieht in etwa so aus:
&myquery ('select a, b, c, d, e from KundenPF inner join UmsatzPF on etc=blabla WHERE a=b')
&V1 wird: %SST(&myquery 1 55) = 'select a, b, c, d, e from KundenPF inner join UmsatzPF '
&V2 wird: %SST(&myquery 56 55) = 'on etc=blabla WHERE a=b'
Im QM-Qry wird das ganze dann jedoch so zusammengesetzt:
"select a, b, c, d, e from KundenPF inner join UmsatzPFon etc=blabla WHERE a=b"
Da steigt er bei mir aus, da der Blank zwischen UmsatzPF und on verloren genagen ist!
Liegt's am Release, oder kann man bei der Variablenübergabe 'was anders machen, so dass führende/folgende Blanks den SETVAR überleben?
Danke und Gruß
Thomas
Nunja, im QMQRY
&V1 &V2 &V3 &V4 &V5
definieren und beim Splitten dafür sorgen, dass nur bei Leerzeichen getrennt wird.
Danke für den Tipp.
Das habe ich mal so umgesetzt!
Zähle ich also ab Stelle 55 zurück bis zum nächsten Blank, dann trenne ich und fülle die nächste Variable.
Einziger Nachteil: Ich kann keine Blanko-Ausdrücke wie z. B. ' abcde ' mehr verwenden, jedenfalls nicht, ohne unsicher zu sein, dass so ein String mit Blanks nicht wieder richtig zusammen gesetzt wird (SETVAR-Trim schnibbelt allles hinweg).
Naja, kann man ja mit leben.
Die Alternative wäre nur noch ein ILERPG mit dynamischem SQL:
d MyStmt 10000 varying
exec sql prepare MyStmt from : MyStmt;
exec sql execute MyStmt;
oder REXX.
Aber das QM-QRY hat schon seine Vorteile v.a . bei der Anzeige einer Select-Klausel, oder beim *PRINT/*OUTFILE.
(Ich verwende das Command gern in Jobs um z. B. Fehlerlisten auszudrucken, da man weder Printerfile noch Druckpgm braucht).
Für UPDATE/INSERT/DELETE-Anweisungen werde ich diese Überlegung per embedded-SQL aber im Hinterkopf behalten!
REXX kenn ich nur von Hörensagen! Was wäre denn der Vorteil davon?
Gruß
Nun ja, REXX kann auch keinen Select ausgeben.
Die Alternative zu diesem Verfahren geht auch noch über einen weiteren Umweg.
Der CRTQMQRY kann eine Quelle in einen QM-Query umsetzen, also mit einem kleinen RPG'le eine SRC schreiben und dann das QM-Query erstellen.
Dynamischer gehts dann wohl kaum noch und du hast dann alle Freiheiten.
Kleines Manko am Rande:
QM-Query kann nur max. 255 Felder als endgültige Ausgabe, zumindest bekomme ich eine entsprechende Meldung.
Und noch ein Tipp (Eigennutz :))
Mit meinem SQLCPY kann man auch ne Menge machen.