SQLRPGLE und Fehlerbehandlung zur Laufzeit

[linguin]

Hallo zusammen,

ich nutze einfache SQLRPGLEs um aus CLs SQL mit Parametern auszuführen.
Funktioniert auch 1a.

Jedoch habe ich das Problem das sich der SQL bei Fehlern so gar nicht meldet.
z.B: wenn ich einen Insert mache, und dieser nicht funktioniert, bekommt man gar nichts davon mit. Er rauscht einfach durch und teilt einem nur im Joblog mit das da was nicht passt.

ein RUNSQLSTM bringt z.B. einen MSGW.

Kann man irgendwie das SQLRPGLE kompilieren damit er auch hängen bleibt ?

Vielen Dank für Eure Infos

Gruß

Linguin

[BenderD]

... works as designed. SQL antwortet mit einem SQLSTATE, bzw. SCLCODE und embedded SQL macht dann weiter. Will man das ändern, muss man den SQLCODE oder SQLSTATE abfragen und kann dann eine escape message schicken, was dann im CL wieder mit MONMSG behandelt werden kann.
Stellt sich mir aber die Frage, wofür das CL gut sein soll?!

D*B

[Fuerchau]

Wenn ich einen native WRITE(E) kodiere frage ich doch auch %error() ab oder lässt du deine Programme dann abstürzen?
Wie Dieter schon sagte, jeder SQL gibt mindestens den SQLCOD bzw. SQLCODE (beides ist zulässtig) zurück, den man abfragen sollte.
= 0 alles OK
< 0 schwerer Fehler
> 0 Warnungen und Hinweise (z.B. 100 = No more Data)

[linguin]

Hallo,

vielen Dank. Das CL macht eigentlich alles. Außer SQL das macht das SQLRPGLE.

Ich habe ein CL (das beherrsche ich) und übergebe an ein einfaches SQLRPGLE die Parameter. Dieses führt ein SQL aus und gibt das Ergebnis (ein oder mehrere Parameter) an das CL zurück. Dann mache ich im CL weiter. Das reicht mir in 99% der Fälle und die Kollegen können es auch lesen

Leider weiß ich nicht wie ich diese SQLSTATE abfragen kann.

Kann mich irgendwer auf ein Codebeispiel verweisen ?

Dann kann mich einlesen.

Vielen Dank.

[BenderD]

... so, wie man jede Variable im RPG abfragt. Handbuch, Google etc. sind dein Freund.

D*B

[andreaspr@aon.at]

https://www.ibm.com/developerworks/c...1-b9de0f2b0e02
https://www.itjungle.com/2014/04/02/fhg040214-story01/
https://www.ibm.com/support/knowledg...a/rzalaccl.htm

Ich bevorzuge auch die Variante in der du auch gleich die SQL Nachricht in deiner Exception weiter gibst:

Exec SQL Get Diagnostics Condition 1 :v_SQLMessage = MESSAGE_TEXT;

Und diese dann mit dem API QMHSNDPM an den Aufrufer senden.

lg Andreas

[Fuerchau]

Wenn ich schon unbedingt einen SQL von CLP ausführen muss, dann nutze einfach das RUNSQL-Command.
Wenn du das ILERPG aufrufst, übergeben einfach einen weiteren Parameter vom Typ DEC(5 0) und im ILERPG stellst du da dann den SQLCODE nach Ausführung rein.

Diese Vorgehensweise ist ansonten eher unüblich und kein nachvollziebarer Stil.

[linguin]

Danke an alle..

@fuerchau: leider habe ich ganz viel von diesem "nicht nachvollziehbarem Stil" geerbt und muss schauen was ich jetzt draus mache. Ich will es einfach absichern und prüfen ob die SQLs sauber durchlaufen.
Ganz umbauen kann ich das leider nicht.

Wobei ich die Geschichte mit dem zusätzlichen SQLRPG auf den zweiten Blick nicht so schlecht finde.
Die SQLRPGs sind (für mich) leichter lesbar wie wie RUNSQL Statements da Parameter ohne Tausend Hochkommas übergeben werden können. Zudem kann ich im SQLRPG mehrere SQL nacheinander aufrufen und die Rückgabeparameter von SQL 1 bei SQL 2 als Input verwenden. Auch prüft das SQLRPG den SQL auf Syntax und Richtigkeit.

@andreas: danke. das werde ich so mal einbauen und testen.

Vielen Dank euch allen

Gruß

Linguin

[BenderD]

Wobei ich die Geschichte mit dem zusätzlichen SQLRPG auf den zweiten Blick nicht so schlecht finde.
Die SQLRPGs sind (für mich) leichter lesbar wie wie RUNSQL Statements da Parameter ohne Tausend Hochkommas übergeben werden können. Zudem kann ich im SQLRPG mehrere SQL nacheinander aufrufen und die Rückgabeparameter von SQL 1 bei SQL 2 als Input verwenden. Auch prüft das SQLRPG den SQL auf Syntax und Richtigkeit.
Linguin

... die Frage ist nicht, ob man das zusätzliche SQLRPG braucht, sondern wofür das zusätzliche CL gut sein soll!!!

D*B

[Fuerchau]

Und ich bezweifle dass im SQLRPG ein Syntaxchecker drin steckt. I.d.R. wird das Statement ja sowieso von SQL beim Prepare geprüft und dann gibts einen negativen SQLCODE.
Beim RUNSQL gibts dann halt einen CPF.

Aber ich gebe Dieter schon Recht.
Wofür ein CLP um SQL's auszuführen?
CLP ist dafür eigentlich nicht gedacht (außer nun neu ab V6 per RUNSQL).

Alternativ würde ich da dann noch REXX vorschlagen. Das ist auch vorhanden, kennt kaum noch jemand und kann neben Commands eben auch SQL, sogar mit Parametern.

[BenderD]

... das mit dem CL ist so eine Sache, so gut wie immer findet man Dutzende modifizierte Copy Varianten und man sollte sich mal überlegen, ob es nicht besser wäre das komplett in RPG zu machen, auch wenn das einen gewissen Lernaufwand erzeugen könnte.

@Baldur: static SQL wird beim compile geprüft.

Dieter

[Fuerchau]

Nun ja, wer weiß was da in dem RPG'le gezaubert wird?
Vielleicht wirds da ja dynamisch...