View Full Version : QWM1939 QMQRY
Ja, die richtige, die ist einmalig
in den details zum Joblog steht S01 mit einem inversen Balken dahinter.
In doppelten Hochkomma, auch Gänsefüßchen genannt:p
Habe mitlerweile ein sql mit execute emediate gemacht, das geht.
Trotzdem ... ich würd gern wissen was ich da ändern muß.
Gruß
schöner WE
Robi
Der inverse Balken sollte da nicht sein. Leg doch die QM-Query nochmal neu an. Andere Frage: Warum machst du eigentlich kein CPYF FROMFILE(ERRORP) TOFILE(ERRORP#S) MBROPT(*ADD) ?
Neu anlegen ... Montag
cpyf ...?
anschließend kommt noch ein delete von bestimmtem Sätzen.
da brauch ich SQL sowieso, (daher auch das Pgm)
Gruß
Robi
Hallo Robi,
interessante Art, die QMQRY zu verwenden.
Ich habe es mal ausprobiert, bei mir geht es auch im Batch.
SBMJOB CMD(STRQMQRY QMQRY(CB2/S01) OUTPUT(*PRINT) SETVAR((S01 'insert into
cb2/cb_kat select * from cb2/cb_kat'))) JOBQ(QINTER)
Ich bekomme zwar interaktiv wie auch im Batch folgende Warnung:
QWM2204 Information 30 28.06.10 09:52:59,745532 QQXSRV01 QSYS *STMT QQXSRV01 QS
Ausgangsmodul . . . . . . . : QQXCPIMESS
Ausgangsprozedur . . . . . : QQxCPIMessage__SendMessage
Anweisung . . . . . . . . . : 16
Zielmodul . . . . . . . . . : QQXINTQUER
Zielprozedur . . . . . . . : QQxIntQuery__RunSQLStatement
Anweisung . . . . . . . . . : 162
Nachricht . . . : Keine Abfragedaten zu PRINT.
Ursache . . . . : Der Befehl PRINT REPORT wurde mit einer Anweisung SQL
SELECT vor der erfolgreichen Beendigung eines Befehls RUN QUERY eingegeben.
Fehlerbeseitigung: Einen Befehl RUN QUERY in einer Abfrage eingeben, die
eine Anweisung SQL SELECT enthält und bei erfolgreicher Beendigung die
Befehlsanforderung PRINT REPORT wiederholen.
aber ausgeführt wird der INSERT in beiden Fällen.
@pikachu: "Aktuell ist doch QWM2010." ROTFL, der war gut!
Gruß, Christian
interessante Art, die QMQRY zu verwenden.
Hab ich öfter im Einsatz
(mein längstes QMQRY heist S10 und hat 10 Variable
&S01 &S02 &S03 ... &S10
da passt ein 550 Zeichen langes sql rein
nicht immer besonders schön, aber häufig hilfreich.
Im Batch hatte ich auch noch nie Probleme.
k.a. warum Das nicht geht.
habe ein anderes pgm, das diese Technik verwendet mal als submit übergeben, kein Problem
echt verrückt
Gruß
Robi
Für solche dynamischen SQL's ist ggf. REXX wesentlich hilfreicher.
Kann ich leider nicht.
Hast du ein 'schreib ab und lerne" Beispiel?
Gib folgendes in eine SEU-Quelle (QREXXSRC) mit Namen RUNSQLSTM ein:
parse arg Stmt
address execsql
execsql "set option commit=*none"
execsql Stmt
exit
Das ganze startest du per:
STRREXPRC SRCMBR(RUNSQLSTM)
SRCFILE(MYSRCLIB/QREXXSRC)
PARM('insert into myfile select ...')
Super, danke
REXX kennt also keine Feldlängen !?
und benötigt die Source für die Ausführung.
Danke, das klingt tatsächlich besser als die blöde Stückelung des SQL in 55 er Variablen
Ich werde es zukünfig so machen
Danke
Robi
(der sich freut das dieses Thema nur doch etwas gebracht und er etwas gelernt hat)
REXX arbeite grundsätzlich mit Strings, das aber sehr komfortabel.
Achtung:
In der Routine ist keine Fehlerbehandlung implementiert!
Probier die Reaktionen bei falschen SQL's mal aus. Im Dialog gibt's dann ggf. eine Bildschirmausgabe die der Bediener bestätigen muss.