STRQMRQY SQLCODE -104

[B.Hauser]

Hast Du auch daran gedacht die alphanumerischen und Datums-Variablen vor dem Aufruf des STRQMQRY in Hochkommata zu setzen?

siehe: http://newsolutions.de/forum-systemi...im-runqry.html

Birgitta

[chera]

Hallo Brigitta,

wenn ich den übergebenen Parameter in Hochkomma setzte erhalte ich folgende Fehlermeldung:

Operanden des Vergleichsoperators = nicht verträglich.
Befehl RUN für Objekt QUERY mit SQLCODE -401 fehlgeschlagen.
Befehl RUN QUERY aufgrund eines Fehlers beendet.
Befehl STRQMQRY fehlgeschlagen.
Funktionsprüfung. QWM2701 nicht überwacht durch EDINCO01C bei Anweisung
0000001703, Instruktion X'0000'.
QWM2701 von Prozedur EDINCO01C empfangen. (C D I R)

Ohne die Hochkomma läuft es interkativ durch, im Stapel jedoch nicht. Wie gesagt, es wird doch immer das gleiche Query aufgerufen. Die Parameter im Query sind beide numerisch.

WHERE BEWEGDATUM = &AWDAT
AND FORTMELDNR = 300

Chera

[chera]

Jetzt wird es aber komisch. Es wird nicht mein übergebener Parameter reklamiert sonder einer der im Query fix abgefragt wird:

WHERE BEWEGDATUM = &AWDAT
AND FORTMELDNR = 300

So sieht das Joblog aus:

Job 092729/BENUTZER/SBMJOB im Subsystem QBATCH in QSYS am 10.01.14 um
08:00:53 gestartet. Job im System am 10.01.14 um 08:00:53. angekommen.
Job 092729/BENUTZER/SBMJOB übergeben.
CALL PGM(TEST/EDINCO00C)
Token FORTMELDNR ungültig. Gültige Token: FOR WITH FETCH ORDER UNION
OPTIMIZE.
Befehl RUN für Objekt QUERY mit SQLCODE -104 fehlgeschlagen.
Befehl RUN QUERY aufgrund eines Fehlers beendet.
Befehl STRQMQRY fehlgeschlagen.
Funktionsprüfung. QWM2701 nicht überwacht durch EDINCO01C bei Anweisung
0000001703, Instruktion X'0000'.
QWM2701 von Prozedur EDINCO01C empfangen. (C D I R)

Nun bin ich ratlos, hat irgendwer eine Idee an was es liegen kann?

Chera

[B.Hauser]

Token FORTMELDNR ungültig. Gültige Token: FOR WITH FETCH ORDER UNION
OPTIMIZE.
Befehl RUN für Objekt QUERY mit SQLCODE -104 fehlgeschlagen.

Nun bin ich ratlos, hat irgendwer eine Idee an was es liegen kann?

Chera

Mit den spärlichen Informationen, die Du uns herüberwachsen lässt, können wir ohne Glaskugel auch nichts sagen.

SQL -104 sagt, dass das Statement nicht in Ordnung ist und zwar vor FORTMELDNR (siehe Fehlermeldung). Also solltest Du SQL-Statement prüfen.

Birgitta

[chera]

Sorry, wollte eigentlich nicht so viel hier reinstellen. Hier nun die restlichen Informationen. Das CL welches das Datum 8-stellig bekommt *char JJJJMMTT, im Query ist es numerisch:

PGM PARM(&P_FIR &P_AWDAT8)

DCL VAR(&P_FIR) TYPE(*CHAR) LEN(1)
DCL VAR(&P_AWDAT8) TYPE(*CHAR) LEN(8)
DCL VAR(&V_NBRRCD1) TYPE(*DEC) LEN(10)
DCL VAR(&V_NBRRCD2) TYPE(*DEC) LEN(10)

/* Arbeitsdateien aus täglichen Bewegungen erstellen */
STRQMQRY QMQRY(GADPP100) OUTPUT(*OUTFILE) +
QMFORM(*QMQRY) OUTFILE(QTEMP/TMP_PP100) +
ALWQRYDFN(*YES) SETVAR((AWDAT &P_AWDAT8))

STRQMQRY QMQRY(GADVZ330) OUTPUT(*OUTFILE) +
QMFORM(*QMQRY) OUTFILE(QTEMP/TMP_VZ330) +
ALWQRYDFN(*YES) SETVAR((AWDAT &P_AWDAT8))

hier das Query nach RTVQMQRY in dem ich den Parameter geändert habe und danach wieder mit CRTQMQRY erstellt habe:

H QM4 05 Q 01 E V W E R 01 03 13/10/01 06:49
V 1001 050 Bewegungssätze GADPP100 (Status 300)
V 5001 004 *HEX
SELECT
ALL FIRMENNR, WOCHENNR, LFDNRPAUFT, POSITIONNR, FORTMELDNR, MELDEDATUM,
MELDSTANDO, MELDPRODST, BANDNRMELD, HINWEISTXT, SACHBEARKZ,
STATUSKENN, BEWEGDATUM, BEWEGNUMME
FROM SC4D1MAN/GADPP100 T01
WHERE BEWEGDATUM = &AWDAT
AND FORTMELDNR = 300
ORDER BY FIRMENNR ASC, WOCHENNR ASC, LFDNRPAUFT ASC, POSITIONNR ASC

Was brauchst du noch? Für mich stellt sich die Frage warum funktioniert es interaktiv und nicht als Stapeljob. Sollte mit dem Parameter etwas nicht stimmen, müsste der Fehler doch bei beiden Varianten kommen.

Chera

[Pikachu]

Bau mal einen DMPCLPGM vor dem STRQMQRY ein und sieh dir in der erstellen Spooldatei mal den Inhalt der Variablen P_AWDAT8 an. Vielleicht ist die ja leer.

[chera]

Danke für den Hinweis. Die Variable ist tatsächlich leer. Jetzt weiß ich zumindest wo ich weiter suchen muss. Vielen Dank!

Danke an alle, oft sieht man vor lauter Wald die Bäume nicht ;-)

Chera