SQL UDF und LibListe

[Nils_V]

Hallo,
ich habe mehrere SQL UDF geschrieben und mittels QM erzeugt (*SVRPGM), indem ich die CREATE FUNCTION Skripte einfach gestartet habe. Die UDF greifen auf unqualifizierte Tabellen zu, der Zugriff erfolgt anhand der LibListe (Ich benutze System Naming). So weit, so gut.

Nun habe ich die Funktionen in das Versionverwaltung ARCAD "gesteckt", und die SQL Skripte (CREATE FUNCTION) sind in SRC Files gespeichert und werden mit CRTSQLOBJ "compiliert". Auch jetzt entstehen *SRVPGMs. Doch sie benutzen zur Laufzeit offenbar nicht mehr die LibListe, sondern suchen die Tabellen in der LIB, in der sie selbst erzeugt wurden und liefern dann einen Laufzeitfehler.

Da die Library, in der die Tabellen stehen, aber wechseln können muss, bin ich auf "den Suchpfad" über die LIBLISTE angewiesen und kann die Tabellen nicht fest qualifizieren.

Hat jemand eine Idee, woran das liegen koennte?

Danke vorab!

Nils

[BenderD]

Hallo,

offenkundig an ARCAD, was immer das sein mag, ich würde mir mal die generierten Serviceprogramme anschauen (PRTSQLINF), da stehen die Compile Options drin, aus dem Repository müssten die auch zu ersehen sein (select * from sysfuncs o.ä.). Möglicherweise kommt man dem ARCAD auch mit set Option ind er SQL Quelle bei, falls ihn das nicht überfordert.
Als Work around für variable Libs ginge da eventuell auch noch ein set schema aus dem Programm vor Ausführung der Function.

mfg

Dieter Bender

Hallo,
ich habe mehrere SQL UDF geschrieben und mittels QM erzeugt (*SVRPGM), indem ich die CREATE FUNCTION Skripte einfach gestartet habe. Die UDF greifen auf unqualifizierte Tabellen zu, der Zugriff erfolgt anhand der LibListe (Ich benutze System Naming). So weit, so gut.

Nun habe ich die Funktionen in das Versionverwaltung ARCAD "gesteckt", und die SQL Skripte (CREATE FUNCTION) sind in SRC Files gespeichert und werden mit CRTSQLOBJ "compiliert". Auch jetzt entstehen *SRVPGMs. Doch sie benutzen zur Laufzeit offenbar nicht mehr die LibListe, sondern suchen die Tabellen in der LIB, in der sie selbst erzeugt wurden und liefern dann einen Laufzeitfehler.

Da die Library, in der die Tabellen stehen, aber wechseln können muss, bin ich auf "den Suchpfad" über die LIBLISTE angewiesen und kann die Tabellen nicht fest qualifizieren.

Hat jemand eine Idee, woran das liegen koennte?

Danke vorab!

Nils

[Nils_V]

Hallo Dieter,

danke für den Tipp! In PRTSQLINF kommt tatsächlich zum Vorschein, dass der Parameter DFTRDBCOL auf die Lib gestellt ist, in der die UDF kreiert wurde. Möglicherweise wird dadurch die Benutzung der *LIB verhindert. (Im anderen Testfall steht er auf *NONE).
Jetzt muss ich schauen, wie ich den Param in ARCAD (www.arcadsoftware.com) verstellen kann.

[B.Hauser]

Hallo Nils

Möglicherweise wird dadurch die Benutzung der *LIB verhindert. (Im anderen Testfall steht er auf *NONE).

Nicht nur möglicherweise, sondern ganz bestimmt!

Wird bei der Default Collection (DFTRDBCOL) eine Bibliothek angegegeben, wird zunächst der Befehl SET CURRENT SCHEMA ausgeführt. Dieser Befehl bewirkt, dass nur die in diesem Befehl angegebene Bibliothek durchsucht wird und die Bibliotheksliste nicht berücksichtig wird. Dies gilt nicht nur für SQL-Naming, sondern auch dann wenn System-Naming verwendet wird.

Birgitta

[Nils_V]

Danke, Birgitta,

ein neues Fragezeichen hat sich ergeben, als ich die Funktion mit RUNSQLSTM und DFTRDBCOL = *NONE erzeugt habe. Sie wurde in einer Lib erzeugt, die gar nicht in meiner Libliste ist!
Gibt es noch einen Parameter, der beeinflusst, IN WELCHER Lib die UDF erzeugt wird? Im CREATE FUNCTION ist der Name nämlich nicht qualifiziert.

Und noch eine Frage: was passiert, wenn ich das SRVPGM einfach mit PDM lösche, mit dem Eintrag in SysFunc? Der ist doch dann nicht mehr korrekt, oder? Also immer mit DROP FUNCTION löschen?

Nils

[BenderD]

Hallo,

drop function ist schon der bessere Weg, damit da keine Inkonsistenzen entstehen. Achtung: Funcrions können überladen werden, da kann es also mehrere gleichnamige im selben Schema geben, die sich durch die Struktur der Parameterliste unterscheiden, dann muss man das beim drop näher spezifizieren.
Als Ort kommen da Curlib und default Schema in Frage, letzteres könnte heißen wie der Benutzer, wenn keines gesetzt wurde.

mfg

Dieter Bender

Danke, Birgitta,

ein neues Fragezeichen hat sich ergeben, als ich die Funktion mit RUNSQLSTM und DFTRDBCOL = *NONE erzeugt habe. Sie wurde in einer Lib erzeugt, die gar nicht in meiner Libliste ist!
Gibt es noch einen Parameter, der beeinflusst, IN WELCHER Lib die UDF erzeugt wird? Im CREATE FUNCTION ist der Name nämlich nicht qualifiziert.

Und noch eine Frage: was passiert, wenn ich das SRVPGM einfach mit PDM lösche, mit dem Eintrag in SysFunc? Der ist doch dann nicht mehr korrekt, oder? Also immer mit DROP FUNCTION löschen?

Nils

[Nils_V]

Danke, Birgitta,

ein neues Fragezeichen hat sich ergeben, als ich die Funktion mit RUNSQLSTM und DFTRDBCOL = *NONE erzeugt habe. Sie wurde in einer Lib erzeugt, die gar nicht in meiner Libliste ist!
Gibt es noch einen Parameter, der beeinflusst, IN WELCHER Lib die UDF erzeugt wird? Im CREATE FUNCTION ist der Name nämlich nicht qualifiziert.

Und noch eine Frage: was passiert, wenn ich das SRVPGM einfach mit PDM lösche, mit dem Eintrag der UDF in der SysFunc table? Der ist doch dann nicht mehr korrekt, oder? Also immer mit DROP FUNCTION löschen?

Nils