SQL UDF erstellen - Best practices

[dschroeder]

3: der Debugger ist schon IBM i-spezifisch, wobei allerdings in meinen Augen der STRDBG der effektivste ist. Auf Grund von SQL-Multthreading funktioniert dies nur sauber per STRSRVJOB von einem Terminal aus. Daher teste ich Funktionen immer per STRSQL und nicht per ODBC, da ich da immer erst den korrekten Job ermitteln muss. Es kann da aber auch ab und an dann ein SQL-Timeout passieren.
Per RDi o.ä. soll es ja auch gehen, aber das ist doch eher fehleranfällig, da ja 2 Systeme beteiligt sind.


Zum Debuggen habe ich doch nochmal eine Frage. Der grafische Debugger aus ACS ist schon recht unhandlich. Deshalb habe ich gedacht, ich befolge deinen Rat und debugge das mit STRDBG.

Ich habe also den Job identifiziert, der das SQL ausführt und habe den entsprechenden STRSRVJOB gestartet.

Dann muss ich ja mit STRDBG das zu debuggende Programm angeben, oder? Das kann ja eigentlich nur das generierte C-Serviceprogramm sein, denke ich. Debuggst du das? Ich würde natürlich gerne meinen SQL-Source step by step durchdebuggen.

Im RDi geht das Debuggen von SQL gar nicht, denke ich. Oder gibt es da doch etwas?

[Andreas_Prouza]

Beim CREATE Statement musst du die debug-View mitgeben:

CREATE OR replace PROCEDURE prouzalib.testproc1 (IN p1 varchar(10))
LANGUAGE SQL
SET OPTION dbgview=*SOURCE
BEGIN
...

Du solltest im STRDBG die Debug-Sicht ändern können.
Im RDi und mitlerweile im vscode kannst du das nach dem gleichen Prinzip debuggen.
Im RDi musst du "Debug für Job" (heißt das glaub ich) auswählen.
Hinterlegt Job + PGM und startest den Debug.
Dann im Greenscreen ins STRSQL und die SQL Funktion oder Prozedur aufrufen.
Du kannst nebenbei auch statt STRSQL ein SQL Tool deiner Wahl benützen, du brauchst nur die Job-Infos der Session

[dschroeder]

Vielen Dank, Andreas.

Ich weiß nicht genau, was ich eben falsch gemacht habe. Aber jetzt wird ohne weiteres Zutun der SQL Code beim STRDBG angezeigt.

Das mit RDi probiere ich morgen mal aus.