Procedure mit Datums Parameter aus SQLStatement aufrufen

[DEVJO]

Moin moin,

ich habe eine Problem ich will aus einem SQL Statement heraus eine Procedure aufrufen, die mir ein Datum aus einem Datum berechnet.
Wenn ich sie "normal" aufrufe bekomme ich das richtige Datum zurück, wenn ich die Procedure nun aber innerhalb eines SQL Statements verwenden will mit einem Feld, welches das Datum enthält, bekomme ich folgende Fehlermeldung:

Nachricht: [SQL0204] P_DATUM der Art *N in Bibliothek nicht gefunden. Ursache . . . . : P_DATUM der Art *N in Bibliothek wurde nicht gefunden. Ist der Teildateiname *ALL, ist die Tabelle nicht partitioniert. Handelt es sich um eine Anweisung ALTER TABLE und ist die Art *N, wurde eine Integritätsbedingung oder Partitionierung nicht gefunden. Ist dies keine Anweisung ALTER TABLE und ist die Art *N, wurde eine Funktion, eine Prozedur, ein Auslöser oder ein Sequenzobjekt nicht gefunden. Wurde eine Funktion nicht gefunden, ist P_DATUM das Serviceprogramm, das die Funktion enthält. Die Funktion wird nur gefunden, wenn der externe Name und der Verwendungsname exakt übereinstimmen. Im Jobprotokoll nach einer Nachricht suchen, die weitere Einzelheiten über den gesuchten Funktionsnamen und den nicht übereinstimmenden Namen enthält. Fehlerbeseitigung: Den Namen ändern und die Anforderung wiederholen. Ist das Objekt eine Knotengruppe, sicherstellen, dass DB2 Multisystem auf dem System installiert ist, und mit dem CL-Befehl CRTNODGRP eine Knotengruppe erstellen. Wurde eine externe Funktion nicht gefunden, das Groß-/Kleinscheibung des EXTERNAL NAME der Anweisung CREATE FUNCTION exakt mit der Groß-/Kleinschreibung des vom Serviceprogramm exportierten Namens übereinstimmen.

Gruß
Jo

[AG1965_2]

Höchstwahrscheinlich stimmt die Type des Übergabeparameters nicht.

[andreaspr@aon.at]

... nein, eine SQL Procedure kann nicht innerhalb eines SQL Statements aufgerufen werden.
Dafür benötigst du eine SQL Function.

lg Andreas

[UFK]

Nein.

Ich vemute (wie schon gesagt) vielmehr, daß bei den Parametern nicht sauber zwischen String und Date unterschieden wurde, und dann kanns sein, daß im interaktiven SQL ein automatisches Casting die Situation rettet, jedoch beim CREATE der Function bzw. Procedure nicht, weil da als erstes nach dem "Unterprogramm" mit der exakt interpretierten Signatur gesucht wird. Diese Suche ist leider gar nicht smart, und verzeiht keine Fehler. Sie sagt dann einfach, Funktion nicht gefunden.

Der Unterschied zwischen Function und Procedure ist vor allem, daß die Procedure meistens was tut (Insert/update usw.), und daß sie über Parameter verfügt, während die Function meistens nichts tut, und meist nur über Input-Parameter und über ein Result, Result-Set der gar eine Result-Table verfügt (und keine Output-Parameter).

Eine Function wird innerhalb einer Formel (im SQL) verwendet.
Eine Prozedur wird innerhalb von SQL mit CALL aufgerufen.

PS: Achte auch darauf, bei Änderungen einer SQL-Function oder SQL-Procedure die vorhergehende Version mit DROP zu entfernen, sonst ergibt sich später ein Chaos. In der Source gebe ich immer zuerst den DROP-Befehl mit der Signatur der aktuellen Version an, ...

[B.Hauser]

Wie sieht den die Paramter-Definition (oder das CREATE-Statement) der Funktion aus?

Wenn Du es aus einem SQL-Statement aufrufen willst, muss es sich um eine (User Defined) Function handeln, d.h. einen Rückgabe-Wert ausgeben werden.
Eine (Stored) Procedure dagegen wird immer mit einem CALL-Befehl aufgerufen.

Sowohl Functions als auch Procedures können überladen werden, d.h. es können mehrere Prozeduren bzw. Funktionen mit dem gleichen Namen jedoch unterschiedlicher Parameter-Definition in der geleichen Bibliothek/Schema vorhanden sein.

Aus diesem Grund muss der Parameter exakt, d.h. mit dem definierten Datentypen (die Länge wird nicht geprüft) übergeben werden. Ggf. muss der Parameter bei Übergabe explizit konvertiert/gecastet werden.

Werden Konstanten oder Ausdrücke übergeben, so wird z.B. bei Zahlen ohne Nachkommastellen der Integer-Datentyp (und nicht etwa der DECIMAL-Datentyp angenommen). Für SQL sind Integer und Decimal unterschiedliche Datentypen und damit wird die Funktion nicht gefunden.

Ähnliches gilt bei alphanumerischen Konstanten. Diese werden als VARCHAR-Datentyp (variable Länge) und nicht als CHAR-Datentyp (fixe Länge) interpretiert. Für SQL sind das unterschieldiche Datentypen und die Funktion wird u.U. nicht gefunden.

Birgitta

[andreaspr@aon.at]

Nein.

Ich vemute (wie schon gesagt) vielmehr, daß bei den Parametern nicht sauber zwischen String und Date unterschieden wurde, und dann kanns sein, daß im interaktiven SQL ein automatisches Casting die Situation rettet, jedoch beim CREATE der Function bzw. Procedure nicht, weil da als erstes nach dem "Unterprogramm" mit der exakt interpretierten Signatur gesucht wird. Diese Suche ist leider gar nicht smart, und verzeiht keine Fehler. Sie sagt dann einfach, Funktion nicht gefunden.

Eine SQL Prozedur kann nur mit einem CALL aufgerufen werden.
Eine SQL Prozedur kann nicht innerhalb eines SQL Statements wie SELECT, INSERT, ... aufgerufen werden. Das geht nur mit einer SQL Funktion.
Man kann eine SQL Funktion vorgelagert verwenden, die dann die SQL Prozedur aufruft, wenn dies notwendig ist.

Der Unterschied zwischen Function und Procedure ist vor allem, daß die Procedure meistens was tut (Insert/update usw.), und daß sie über Parameter verfügt, während die Function meistens nichts tut, und meist nur über Input-Parameter und über ein Result, Result-Set der gar eine Result-Table verfügt (und keine Output-Parameter).

Eine SQL Prozedur kann genauso über ein (oder sogar mehrere) Cusor Result-Sets (Select Abfragen) verfügen.

PS: Achte auch darauf, bei Änderungen einer SQL-Function oder SQL-Procedure die vorhergehende Version mit DROP zu entfernen, sonst ergibt sich später ein Chaos. In der Source gebe ich immer zuerst den DROP-Befehl mit der Signatur der aktuellen Version an, ...

Wer 7.1 hat kann auch mit CREATE OR REPLACE FUNCTION/PROCEDURE arbeiten.

lg Andreas