SQL UDF erstellen - Best practices

[Fuerchau]

Der Greenscreen Debugger funktioniert hier genauso gut, wie oben beschrieben. Ins besonders wenn man remote (Homeoffice) arbeitet, ist der ACS-Debugger einfach unzuverlässig und laaangsaaaaam.

[dschroeder]

@1/2: Sowohl beim CREATE PROCEDURE als auch beim CREATE FUNCTION kann man den (Service-)Programm-Namen (mit Option PROGRAM_NAME) angeben. Den (Service-)Programm-Namen kann man (selber) festlegen und ist auf 10 Stellen beschränkt.
...Der Programm-Name kann unabhängig von dem SPECIFIC NAME festgelegt werden. Der SPECIFIC Name dient in erster Linie dazu, die aufgerufene Funktion/Prozedur (bei Überladungen) eindeutig zu lokalisieren.
Der Source Code ist beim CREATE OR REPLACE Statement hinterlegt, d.h. jedes CREATE Statement generiert ein eigenes Objekt. Wenn man mehrere CREATE Statements in der gleichen Quelle hat, werden eben mehrere Objekte/Programme/Service-Programme mit einer exportierten Funktion generiert.

Hallo Birgitta,
vielen Dank für deine Infos. Genau das Schlüsselwort PROGRAM_NAME kannte ich bisher nicht. SPECIFIC_NAME habe ich bisher auch bei Überladungen eingesetzt.

Ist es eigentlich eine gute Idee, das C-Programm mit PROGRAM_NAME selbst zu benennen? Ich dachte, es wäre eine gute Idee. Aber jetzt kamen bei uns Bedenken auf, dass das auch eine riskante Fehleroption sein kann: Wenn jemand eine UDF (also den Source) kopiert und eine neue Funktion schreibt und dabei vergisst, den PROGRAM_NAME anzupassen, wird die neue Funktion ja wahrscheinlich erstellt, aber das bestehende C-Programm wird fälschlicherweise überschrieben.

Siehts du oder seht ihr das auch als Problem?

Wir liebäugeln deshalb zur Zeit doch mit der Lösung, den C-Programmnamen automatisch generieren zu lassen und uns für die Debugzwecke das C-Programm manuell (z.B. mit SQL) heraus zu suchen.

[BenderD]

... das generieren lassen ist selten eine gute Idee, insbesondere wenn die generierten Namen von der Reihenfolge der Erstellung von Programmen abhängen und man mehrer Umgebungen hat - noch verschärft, wenn man kein automatisches Deployment und change management hat.

D*B

[Fuerchau]

Das kann dir auch bei RPG passieren, wenn man den Namen im Programm vergeben hat, was allerdings eher selten gemacht wird.
Die COBOL-Programmierer kennen das aber, da ist der Name in der Source ja Pflicht;-).

[dschroeder]

... das generieren lassen ist selten eine gute Idee, insbesondere wenn die generierten Namen von der Reihenfolge der Erstellung von Programmen abhängen und man mehrer Umgebungen hat - noch verschärft, wenn man kein automatisches Deployment und change management hat.
D*B

Das ist richtig. Danke für den Hinweis.

Ich habe noch ein wenig weiter probiert. Bei mir klappt die Angabe des Programmnamens nur, wenn ich das Schlüsselwort "specific" verwende. PROGRAMM_NAME oder "specific name" funktioniert nicht.
Oder wie soll das genau gehen?

Wegen des Überschreibens von generierten Programmen bin jetzt auch etwas beruhigter:
Wenn man einmal einen "specific" Programmnamen festgelegt hat, kann man den gar nicht so einfach von einer anderen Funktion aus überschreiben. Es gibt dann die Meldung, dass der Name bereits verwendet wird.

[Andreas_Prouza]

Wegen des Überschreibens von generierten Programmen bin jetzt auch etwas beruhigter:
Wenn man einmal einen "specific" Programmnamen festgelegt hat, kann man den gar nicht so einfach von einer anderen Funktion aus überschreiben. Es gibt dann die Meldung, dass der Name bereits verwendet wird.

Naja, ich verwende das CREATE OR REPLACE.
Da ich automatisierte Builds verwende, muss die bestehende Funktion vorher gelöscht werden, falls diese bereits vorhanden ist.
Da ich das nicht jedes mal manuell machen möchte (was ja auch wieder fehleranfällig ist) muss man entweder in der Source vorher ein DROP FUNCTION oder eben das OR REPLACE verwenden.

[dschroeder]

Wir verwenden ebenfalls nur create or replace.

Ich finde es ja supergut, dass man den specific Name nicht einfach von einer anderen Funktion aus nochmal benutzen kann. Diese Gefahr ist durch die Warnung gebannt.

[dschroeder]

Bevor jemand den Unsinn, den ich geschrieben habe, für bare Münze nimmt, hier nochmal eine Richtigstellung:

Ich habe inzwischen herausgefunden, dass es doch das Schlüsselwort "program name" gibt. (Mein RDi erkennt das allerdings nicht als Schlüsselwort, aber es lässt sich ausführen.)

Das heißt:

• Mit program name kann ich selbst den Namen des C-Programms festlegen
• Mit specific lege ich den eindeutigen Funktionsnamen fest. Z.B. wenn ich die selbe Funktion mit unterschiedlichen Parametern haben möchte.

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