ShowCase und UDF

[andreaspr@aon.at]

Vielleicht gibt es ein Problem bei den Parametern (Stichwort VARCHAR und CHAR).
Du könntest auch den Databasemonitor starten. Dort bekommst du zumindest eine bessere Fehlermeldung zu sehen.

lg Andreas

[Fuerchau]

Wichtig zu wissen ist, wo du die UDF registriert hast.
Üblicherweise hat man da eine Programmlib und nicht die Datenlib.

Per STRSQL arbeitest du mit *SYS-Naming, so dass die UDF gefunden werden kann.
Im Squirrel kannst du ggf. ja auch *SYS-Naming in der Verbindung angeben.

Showcase arbeitet nun ggf. mit *SQL-Naming, was bedeutet, dass die UDF nicht mehr gefunden wird.

Wenn du deine View erstellst, dann qualifiziere den Aufruf deiner UDF.

'*N'-Meldungen bekomme ich auch, wenn die
- UDF selber nicht gefunden wird
- die Parameter-Typen einer UDF nicht gefunden werden

Man kann nämlich durchaus mehrere UDF's mit dem selben Namen haben, wenn denn die Parameter unterschiedlich sind.

Es könnte also nun am "umschreiben" des SQL's durch den Optimizer liegen (der liest ja die Info aus der View) und deshalb die UDF nicht gefunden wird.

[alexk2013]

Vielleicht gibt es ein Problem bei den Parametern (Stichwort VARCHAR und CHAR).
Du könntest auch den Databasemonitor starten. Dort bekommst du zumindest eine bessere Fehlermeldung zu sehen.

lg Andreas

Hallo Andreas,

ich habe alles VARCHAR definiert.

D.h., in der SQL UDF und in der RPG Prozedur.

Wie gesagt: Es läuft unter anderen externen SQL-Clients (z.B. Squirrel) und über die Terminal-Sitzung via STRSQL.

Nur ShowCase kann es nicht.

Viele Grüße

Alex

[alexk2013]

Wichtig zu wissen ist, wo du die UDF registriert hast.
Üblicherweise hat man da eine Programmlib und nicht die Datenlib.

Per STRSQL arbeitest du mit *SYS-Naming, so dass die UDF gefunden werden kann.
Im Squirrel kannst du ggf. ja auch *SYS-Naming in der Verbindung angeben.

Showcase arbeitet nun ggf. mit *SQL-Naming, was bedeutet, dass die UDF nicht mehr gefunden wird.

Wenn du deine View erstellst, dann qualifiziere den Aufruf deiner UDF.

'*N'-Meldungen bekomme ich auch, wenn die
- UDF selber nicht gefunden wird
- die Parameter-Typen einer UDF nicht gefunden werden

Man kann nämlich durchaus mehrere UDF's mit dem selben Namen haben, wenn denn die Parameter unterschiedlich sind.

Es könnte also nun am "umschreiben" des SQL's durch den Optimizer liegen (der liest ja die Info aus der View) und deshalb die UDF nicht gefunden wird.

Hallo Herr Fuerchau,

also die UDF habe ich nach alter Art via SYS-naming mit RUNSQLSTM aus einem File-Source-Member registriert (lib/file im sql code).

Das SQL für die View habe ich aus einer Streamfile importiert und mit RUNSQLSTM mit SQL-naming registriert (lib.file im sqlcode). Sysnaming hat hier nicht geklappt, habe alles schon mal auf SYS-naming im Streamfile umgelötet - aber er hat es nicht gefressen, daher bin ich bei SQL-naming geblieben.

Gut, die Funktion und View und Daten sind nicht in derselben Bibliothek.
Die Funktion UDF und das RPG und die View sind in einer (QGPL for general purpose...) und die Daten in einer anderen Bibliothek.

Interessanterweise läuft die View ja über den externen Client Squirrel. Eine Bibliotheksliste ist dort nicht von mir angegeben unter Driver properties.

Allerdings ist in den Connection Properties "Specify Shema loading and caching" angegeben, das sollte aber nur frü den Objekt-Tree und sich wohl nicht auf die SQL-Ausführung auswirken.

Ich werde mal sehen, ob ich alles über SQL-naming via RUNSQLSTMT mit File-Source-Member glattziehe auf die klassische Art...


MFG

Alex

[Fuerchau]

Wenn du die UDF mittels "QGPL.MYUDF(...)" in der View mit SQL-naming verwendest, sollte es funktionieren.
Die QGPL wird per Default (Systemwert QUSRLIBL) in die SQL-Serverjobs mit reingenommen wenn man keine Lib-Liste in der Verbindung angibt.

[alexk2013]

Ach, dazu kommt natürlich, daß der externe Squirrel Client mit JDBC und das ShowCase mit ODBC läuft.

Zumindest wird er über ODBC-Datenquellen-Administrator verwaltet und zugeordnet und nennt sich SCOJDBC.DLL. (wer weiß Warum scoJDBC.Dll).

Hier hören aber meine Kenntnisse auf, da die Installation vorpaketiert sind ...

[alexk2013]

Wenn du die UDF mittels "QGPL.MYUDF(...)" in der View mit SQL-naming verwendest, sollte es funktionieren.
Die QGPL wird per Default (Systemwert QUSRLIBL) in die SQL-Serverjobs mit reingenommen wenn man keine Lib-Liste in der Verbindung angibt.

Die UDF ist in der View so deklariert. Ich kann höchstens noch mal auf "uppercase" umstellen.

Was die Bilbiotheksliste betrifft: Mein Erfahrung ist, sie wirkt sich nicht bei jedem SQL Clienten aus. Jedenfalls weden ohne library Angabe keine Dateien erkannt (SQL-naming).

Bei ShowCase ist es wohl so - es ist dort separat vordefiniert.

Ich werde es morgen mal versuchen...

Schönen Abend noch...

[Fuerchau]

Die 1. Lib der Libliste ist meist die "Defaultlib".
Die Defaultlib lässt sich auch separat definieren.
Ohne Libliste wird eine Lib mit Namen des Users gesucht.

[B.Hauser]

Die 1. Lib der Libliste ist meist die "Defaultlib".
Die Defaultlib lässt sich auch separat definieren.
Ohne Libliste wird eine Lib mit Namen des Users gesucht.

Beim SQL-Naming ist die Bibliotheksliste zumindest für Tabellen und View völlig belanglos. Unqualifiziert angegebene Tabellen/Phys.Dateien und Views werden in der Default-Library gesucht. Sofern diese nicht explizit gesetzt wurde z.B. mit dem SQL-Befehl SET SCHEMA oder in irgendeiner ODBC oder JDBC-Einstellung entspricht das DEFAULT-Schema dem angemeldeten Benutzer-Profil.

Andere Objekte z.B. Stored Procedures, User Defined Functions oder Sequence Objekte werden bei Verwendung von SQL-Naming im SQL-Pfad gesucht. Im SQL-Pfad können mehrere Bibliotheken/Schemas angegeben werden, die wie bei der Bibliotheksliste sequentiell durchgesucht werden. Der SQL-Pfad kann über den SQL-Befehl SET PATH gesetzt werden. Der Sonderwert *LIBL ist zulässig. Damit kann auch bei SQL-Naming die Bibliotheksliste nach Datenbankenobjekten, die weder Tabellen/phys.Dateien noch Views sind duchsucht werden. Der Default-Wert beim SQL PATH, sofern nicht anderweitig gesetzt ist *LIBL.

Weiterhin muss berücksichtigt werden, dass die Berechtigungen unter System- und SQL-Naming unterschiedlich behandelt werden.

Hier sind zwei Artikel zum Unterschied zwischen SQL und System-Naming:
SQL versus System Naming - Part I
SQL versus System Naming - Part II

Birgitta

[BenderD]

... das mit SQLPATH, LIBL & Co. simd doch für SQL alles Fremdworte. Der Rest der Welt (und der ist größer) denkt in Schema.
Wenn Du Dir alle Probleme vom Hals halten willst:
- pack alles, was zu einer Datenbank gehört (Tables, Views, Functions,stored Procedures und alle davon abhängigen Objekte (inklusive Deiner wertvollen RPG-Hams) in eine Lib.
- leg einen Benutzer an, der wie diese Lib heißt (aus Berechtigungsgründen ohne interaktive Anmeldung
- mach diesen User zum Owner von alledem
- mach alle connects unter diesem Benutzer
- et voila: alles funzt, ohne irgendwelchen Krumschel
- nebenbei hast Du damit auch Deine SAV/RST Abläufe alle einfachst im Griff: alles funzt!!!

D*B,
der sich gerne Probleme vom Hals hält, die man nicht haben muss!!!

[Fuerchau]

@Birgitta
Was anderes habe ich ja auch nicht behauptet.

Das erklärt aber immer noch nicht, warum alle anderen ODBC/JDBC-Clients mit der View zurecht kommen und ShowCase eben nicht.

[BenderD]

... ich kenne zwar Showcase nicht, aber manche solcher Produkte haben eigene Treiber oder verwenden eine System DSN und benötigen spezifische Einstellungen.

D*B