-
SQLCSR und SBMJOB
hallo,
ich hätte eine frage. der unten stehende code stammt aus einer prozedur p1, die ich im programm p9a in einer schleife bei jedem durchlauf aufrufe und bei jedem aufruf mit einem sql-statement (select * from tmp660 where belnr = 'xyz, wobei sich der wert von belnr bei jedem durchlauf ändern kann) als input-parameter fülle.
rufe ich das programm p9a normal per call auf funktioniert alles prächtig.
wenn ich jedoch ein CL darum stricke (hier p9cl genannt) und das programm p9a darin per SBMJOB ausführe, bekomme ich beim ausführen des sql-statements in der prozedur einen fehler mit sqlstate 24501 (fetch auf cursor der nicht geöffnet wurde...).
ich hab nun schon einiges versucht aber mittlerweile gehen mir die ideen aus.
vielleicht kann mir wer helfen (die formatierung des codes funktioniert leider nicht besser, sorry).
vielen dank!
if pi_SqlStmt = *blanks;
return *off;
else;
xStmt = pi_SqlStmt;
endif;
exec SQL
declare SQLCSR15 cursor with hold for DYNSQLSTMF;
exec sql
close SQLCSR15;
exec sql
prepare DYNSQLSTMF from :xStmt;
exec sql
open SQLCSR15;
exec sql
fetch next from SQLCSR15 into :xDGBELNR;
if SQLSTT < SQL_NO_ROW;
exec sql
close SQLCSR15;
return *on;
else;
exec sql
close SQLCSR15;
return *off;
endif;
-
Dein Programm erwartet einen SQL als Parameter.
Beim SBMJOB musst du diesen Parameter in der Länge des erwarteten Feldes in Hochkomma übergeben.
Ansonsten hast du im Parameter halt Schrott nach dem SQL an dem der Prepare dann scheitert.
-
hallo fuerchau,
vielen dank für die rasche antwort :-).
aber ich submitte doch den job zuerst (SBMJOB CMD(CALL PGM(P9A)) und im programm p9a läuft dann die schleife mit dem wiederholten aufruf der prozedur p1, in der ich dann mit dem cursor arbeiten will.
-
Schau mal im Joblog. Für mich klingt das eher nach einem Folgefehler. Eventuell findest du im Joblog schon einen Fehler warum das OPEN CURSOR schon nicht ging.
lg Andreas
-
das sql-statement bau ich mir ja erst im submitteten programm zusammen. egal ob ich das sql dann in diesem programm (declare, open, prepare, fetch, close) oder in einer ausgelagerten prozedur (an die ich das sql-statement per string übergebe) ausführe, ich bekomme immer diesen fehler.
ich verwende im selben programm noch einen anderen cursor, der komischerweise immer funktioniert (bei aufruf des programms mit call oder per sbmjob).
-
Wenn du hier nur Bruchstücke vom Code darstellst könnne wir nur raten.
Wenn du aus dem CLP das Programm P9A per "CALL P9A (&VAR)" aufrufst klappt es, beim "SBMJOB CMD(CALL P9A (&VAR))" klappt es nicht.
Dies ist auch kein Wunder, wenn &VAR länger als 32 Zeichen ist.
Mach ein
"SBMJOB CMD(CALL P9A (&VAR *CAT 'X'))"
draus. Erklärungen findest du hier hier im Forum, da wir das schon ganz viele male hatten.
-
guten morgen,
jetzt funktioniert es. vielen dank fuerchau für ihre hilfe. das *cat 'X' war wohl die lösung :-).
Similar Threads
-
By max40 in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 21-01-16, 15:37
-
By malzusrex in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 22-03-15, 06:33
-
By sirdidi in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 24-01-14, 10:31
-
By horst in forum IBM i Hauptforum
Antworten: 8
Letzter Beitrag: 15-01-02, 06:55
-
By muadeep in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 13-11-01, 15:05
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks