SQL UDFs und RPG, Probleme bei optionalen Parametern

[dschroeder]

Hallo,
heute habe ich mal keine Frage, sondern nur einen Hinweis. Wenn wir User defined Functions in SQL geschrieben haben, die ein RPG-Programm verwenden, dann haben wir optionale Parameter immer in der folgenden Form behandelt:



dcl-proc testproc *export;
dcl-pi *n;
fromDate date(*iso) options(*nopass:*omit);
end-pi;
if %parms >= %parmnum(fromDate) or %parms < 0 and %addr(fromDate) <> *NULL;
myDate = fromDate;
endif;
end-proc;


Falls das Programm von einem anderen RPG-Programm aufgerufen wird, wirkt der Teil:
if %parms >= %parmnum(fromDate)

Falls das Programm von SQL aufgerufen wird, werden keine Parameter über die RPG-Parameter-Strategie übergeben. Stattdessen gibt %parms = -1 übergeben. Es wirkt also folgender Code:
if %parms < 0 and %addr(fromDate) <> *NULL;

Das codieren wir bereits seit Jahren so und es hat bisher keine Probleme gemacht. Gerade hat Barbara Morris im developerWorks Formum geschrieben, dass das Verfahren so nicht sicher ist. Sie schreibt sogar, dass es unmöglich sei, in RPG sicher festzustellen, ob ein Parameter von SQL aus übergeben wurde.

Also aufpassen und optionale Parameter lieber direkt im SQL handeln.

Dieter

[B.Hauser]

Deshalb gilt auch, dass man für externe UDFs mit optionalen Parametern für jede Parameter-Kombination eine (RPG)-Funktion generiert, die nichts anderes macht als die Orignial-Funktion aufzurufen. Diese Funktionen werden dann alle mit dem gleichen Namen (Überladung) registriert.

Alternativ kann man auch die externe Funktion mit allen Parametern registrieren und bei den optionalen Parametern Default-Werte hinterlegen. Werden beim Aufruf der Funktion dann nicht alle Parameter übergeben, werden für die fehlenden Parameter die Default-Werte übergeben.

Birgitta

[dschroeder]

Danke Birgitta.
Wir werden in Zukunft vorsichtiger sein bei optionalen Parametern.

Dieter