SQL UDF erstellen - Best practices

[Fuerchau]

1: "specific name" gibt den 10-stelligen Namen an.
2: Das passiert leider nicht automatisch, da hätte ja einer mitgedacht. Man kann aber auch IFS-Dateien nehmen bzw. PC-Dateien, und dann?
Der Wartbarkeit wegen: 1 Funktion/Prozedur/Type o.ä. => 1 Datei, denn damit generiert man nur das Programm, dass sich ändert. Du kannst natürlich auch alles in eine Quelle packen. Ich habe da dann nur Probleme immer mit dem Semikolon;-).
Außerdem mache ich das ja auch per Datei/Index/Constraint/Trigger.
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.
Über "set options DBGVIEW = *SOURCE" ist das Debuggen auch einfacher.
4: s.o.

Und da eben auch nicht alles per SQL geht, schreibe ich auch gerne SQL-Procedure/Function mit external RPG im SQL-Stil (Parameter + Nullanzeiger + SQL-Variablen).
Und da manchmal SQL nicht direkt gewünscht ist, auch schon mal Service-Wrapper in ILERPG, die dann trotzdem die SQL-Function aufrufen.

[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.