Hi Forum

[TUM]

Ein Kollege hat eine Problem mit SQL:

SQL0444: Externes Programm WEA000 in MHISINST nicht gefunden.
Ursache . . . . : Es wurde versucht, Prozedur oder Funktion WEA000 in HEKANEU2 aufzurufen. Das externe Programm oder Serviceprogramm WEA000 in Schema MHISINST wurde nicht gefunden. Fehlerbeseitigung: Das externe Programm oder das Serviceprogramm, das der Prozedur oder Funktion zugeordnet ist, kann nicht gefunden werden. Sicherstellen, dass ein Objekt mit dem in der Anweisung DECLARE PROCEDURE, CREATE PROCEDURE, CREATE FUNCTION, ALTER PROCEDURE oder ALTER FUNCTION angegebenen Namen vorhanden ist. Wurde kein Name angegeben, sicherstellen, dass ein Objekt mit einem Namen vorhanden ist, der dem angegebenen Prozedur- oder Funktionsnamen entspricht. Wurde ein Programmname angegeben, muss ein Programmobjekt vorhanden sein. Wurde der Name eines Eingangspunkts angegeben, muss ein Serviceprogrammobjekt vorhanden sein. Die Anforderung wiederholen.

Jetzt ist es so, dass MHISINST der Benutzer ist, mit dem er sich bei der I angemeldet hat.
Eine Bibliothek mit diesem Namen gibt es nicht.

Kann uns da jemand helfen. Vielen Dank schon mal.

[Fuerchau]

Dieses Problem triit auf, wenn man NAMING=*SQL verwendet, kein Default-Schema angibt und Prozeduren unqualifiziert aufruft.
In diesem Fall versucht SQL eine Lib mit dem Anmeldenamen zu finden.
Lösung:
call mylib.myproc(....)

[TUM]

Danke für die schnelle Antwort, werde ich weiterleiten.

[B.Hauser]

Das Problem hängt tatsächlich mit dem SQL Naming zusammen.
Der Unterschied zwischen SQL und System-Naming ist weit mehr als das unterschiedliche Trennzeichen zwischen Schema und Objekt.
Allerdings hat das Default oder Current Schema hat nichts mit Prozedur- oder Funktions-Aufrufen zu tun.

Beim SQL Naming werden nur die unqualifiziert angegebenen Tabellen, physische Dateien, logische Dateien, Indices und Views in dem Default/Current Schema gesucht.

Die unqualifiziert angegebenen Stored Procedures, Trigger und User Defined Functions werden dagegen über den SQL Path gesucht.
Selbst wenn das Default Schema richtig gesetzt wurde, die Objekt-Bibliothek jedoch nicht im SQL Pfad hinterlegt wurde, wird das Objekt nicht gefunden.

Beim SQL Pfad können mehrere Schemata oder Bibliotheken angegeben werden. Diese werden genau wie eine Bibliotheksliste durchsucht und sogar der Sonderwert *LIBL kann gesetzt werden.

z.B.
SET CURRENT PATH MySchema1, MySchema2, ... MySchemaN;
SET CURRENT PATH *LIBL;

Birgitta

[Fuerchau]

Dann stellt sich mir die Frage, wieso bei obigem Fehler das Default-Schema, also der User, gemeldet wurde?
Wenn ich explizit nichts angebe liefert mir
select current schema, current path from sysibm.sysdummy1

Current Schema: FUERCHAU
Current Path: QSYS, QSYS2, SYSPROC, SYSIBMADM, FUERCHAU

Nun habe ich in der Verbindung die Schemaliste gesetzt.
Die obige Abfrage lifert nun

Current Schema: FUERCHAU
Current Path: *LIBL

Der Aufruf "CALL XXX('YYY')" liefert nun XXX in FUERCHAU nicht gefunden.
Wie passt das zu deiner Aussage?

Und noch was:
Hänge ich einen Trigger, per SQL oder per CMD, an eine Tabelle/PF wird dieser immer qualifiziert in die Datei eingetragen. Eine Suche per *LIBL ist daher unnötig.
Ich prüfe daher z.B. in meinen Triggern, ob ggf. zusätzlich benötigte Lib's in der LIBL stehen und wenn nicht, füge ich diese hinzu.

[BenderD]

... das Problem liegt eine Stufe tiefer:
Wenn es denn die Procedure/Function im Schema FUERCHAU gäbe, würde dazu ein Programm gehören - im Falle einer SQL Routine das generierte C Programm - das nun wiederum im SQL Path gesucht wird.

D*B

PS:
Macht man sich das Leben leicht, ist das einfach zu bewerkstelligen:
- Datenbank mit Name des Owners anlegen
- alle Objekte unter diesem Owner erstellen
-- alles landet in der Datenbanklib, die Routinen kriegen den SQL Path korrekt gesetzt
- andere Benutzer per GRANT berechtigen.
Zugriff erfolgt dann per setzen des Default Schemas oder qualifiziert - alles unter SQL naming.

Damit ist man nicht nur SQL Standard kompatibel, sondern es hört auch der Dummfug auf, Dateien per Libl zu suchen. (Da hat man eine Datenbank mit referential integrity und sagt dann beim Zugriff: schau mal ob Du im LIBL einen Kundenstamm findest, aus dem Du Dir die Kundeninfos zum Auftrag holst - Schilda lässt grüßen)

[Fuerchau]

Also das macht doch wirklich Sinn.
Zuerst wird die Prozedur in den Definitionen (wegen Überladung, Parameterprüfung) mit FUERCHAU gesucht.
Wenn gefunden erfolgt irgendwann der CALL per PATH.
Vergesse ich also, mein Schema zusätzlich in den PATH einzutragen, bekomme ich zwar keinen SQL0444 sondern einen MCH-Fehler, da das eigentliche Objekt nicht gefunden wurde.
Wer denkt sich nur sowas aus.

Übrigens:
Wie mache ich mit NAMING=*SYS eine qualifizierte Objektbenennung?
SQL wirft mir den "/" immer als Fehler raus.

[BenderD]

Also das macht doch wirklich Sinn.
Zuerst wird die Prozedur in den Definitionen (wegen Überladung, Parameterprüfung) mit FUERCHAU gesucht.
Wenn gefunden erfolgt irgendwann der CALL per PATH.
Vergesse ich also, mein Schema zusätzlich in den PATH einzutragen, bekomme ich zwar keinen SQL0444 sondern einen MCH-Fehler, da das eigentliche Objekt nicht gefunden wurde.
Wer denkt sich nur sowas aus.

Übrigens:
Wie mache ich mit NAMING=*SYS eine qualifizierte Objektbenennung?
SQL wirft mir den "/" immer als Fehler raus.

... bei oben skizzierter Vorgehensweise wird der korrekte SQL path im repository eingetragen.
Qualifier ist im ANSI SQL immer der Punkt.

select OTTO.KARL from HUGO.OTTO etc.

oder select ... from KARL.HUGO.OTTO - dann ist KARL die Datenbank und HUGO das Schema

Dieter

PS: hoffentlich übersehen die Wächter der blauen Korrektness die defätistische Bemerkung (Wer denkt sich nur sowas aus.), sonst wird wieder nicht ausreichende Flachheit reklamiert - Uih. Uih, Uih...

[andreaspr@aon.at]

PS: hoffentlich übersehen die Wächter der blauen Korrektness die defätistische Bemerkung (Wer denkt sich nur sowas aus.), sonst wird wieder nicht ausreichende Flachheit reklamiert - Uih. Uih, Uih...

Zumindest zeigt es, dass es Spuren hinterlassen hat!

[Fuerchau]

@Dieter
Korrekterweise bezeichnet dann "KARL.HUGO.OTTO.FELD" das eigene Feld.
Bei "from KARL.HUGO.OTTO X" würde dann wieder "X.FELD" reichen.
Das Problem besteht dann immer halt nur mit sog. Testumgebungen, wo man mal die eine oder andere einzelne Tabelle temporär auslagert, wo aus HUGO dann schon mal WILHELM werden muss.
Aber das kann man ja dann auch noch mit OVRDBF schön verstecken.

[BenderD]

Das Problem besteht dann immer halt nur mit sog. Testumgebungen, wo man mal die eine oder andere einzelne Tabelle temporär auslagert, wo aus HUGO dann schon mal WILHELM werden muss.
Aber das kann man ja dann auch noch mit OVRDBF schön verstecken.

... genau da fängt doch das Problem an, wo man Testumgebungen durch partielle Verdeckungen erzeugt. sei es durch OVRDBF oder durch vorschalten einer unvollständigen Testumgebung vor eine produktive Umgebung und hinterher wundert man sich woher die "eigentlich unmöglichen" Sätze in produktiven Umgebungen kommen...

Dieter

[Fuerchau]

Leider, wie in einem aktuellen Fall, habe ich keine Chance mit mehreren 100GB eine Testumgebung aufzubauen. Somit verwende ich halt Naming=*SYS und habe keine weiteren Probleme.
Aber, da gabe ich dir Recht, dass muss man dann qualifiziert tun und darf es nicht jedem überlassen.

Wie in einem anderen Thread ja schon angemosert bekommt man hier wieder viel zu viele Antworten auf nicht gestellte Fragen. Der Fragesteller hat sich ja schon verabschiedet.