View Full Version : ShowCase und UDF
andreaspr@aon.at
03-09-13, 14:44
Diesmal mit der Warnmeldung *N.
Gibt es vielleicht eine genauere Fehlermeldung zu *N?
Hallo Andreas,
leider nicht. Die Meldung erscheint im Client Fehler Fenster - hätte ich sonst gepostet.
andreaspr@aon.at
03-09-13, 15:11
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
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.
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
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
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.
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 ...
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...
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.