Die CALL-Anweisung ruft eine Routine auf.
Die aufgerufene Routine muss in Einklang mit ihrer Definition aufgerufen werden. Wenn z. B. eine Routine mit drei Parametern definiert wurde, von denen die ersten beiden eine Ganzzahl und die dritte ein Zeichen ist, muss die CALL-Anweisung drei Variablen an die Routine weiterleiten. Dabei muss der jeweilige Datentyp der Definition entsprechen. Dieser Vorgang wird genauer Signaturabgleich genannt, d. h., die Signatur der CALL-Anweisung muss mit der Signatur der Routinendefinition übereinstimmen.
Der genaue Signaturabgleich wird auch auf den Rückgabewert einer Routine angewendet. Wenn die RETURNS-Klausel in der CREATE FUNCTION-Anweisung angegeben ist oder wenn es sich bei der Routine um eine integrierte Funktion handelt, muss die INTO-Klausel in der CALL-Anweisung angegeben werden. Rückgabewerte von Routinen können nicht ignoriert werden. Umgekehrt gilt: wenn die RETURNS-Klausel nicht in der CREATE FUNCTION-Anweisung angegeben ist, muss die INTO-Klausel nicht angegeben werden, da kein Rückgabewert der Routine vorliegt.
Diese Vielfalt der Implementierungsmöglichkeiten bedeutet, dass einige der Klauseln im CALL-Syntaxdiagramm nicht für alle Routinetypen zutreffen (oder nicht zulässig sind). Zudem ermöglicht sie der CALL-Anweisung, jeden beliebigen Routinetyp - unabhängig davon, wie die Routine definiert wurde - aufzurufen.
Wenn der optionale Brokerschemaname-Parameter nicht angegeben ist, sucht der SQL-Parser des Brokers mit dem in der PATH-Anweisung beschriebenen Algorithmus nach der genannten Prozedur (siehe PATH-Klausel der BROKER SCHEMA-Anweisung).
Wenn der Brokerschemaname-Parameter angegeben ist, ruft der SQL-Parser des Brokers die genannte Prozedur im angegebenen Schema auf, ohne zuerst nach dem Pfad zu suchen. Ist die Prozedurreferenz jedoch mehrdeutig (d. h. es gibt zwei Prozeduren mit identischem Namen in unterschiedlichen Broker-Schemas) und die Referenz wird nicht vom optionalen Brokerschemaname-Parameter angegeben, generiert das Eclipse-Toolset einen "Tasksanzeigefehler", den Sie korrigieren müssen, um den mehrdeutigen Code zu implementieren.
Die vom Broker bereitgestellten integrierten Funktionen werden automatisch in ein vordefiniertes Broker-Schema namens SQL platziert. Das SQL-Schema wird stets zuletzt nach einer Routine durchsucht, die nicht mit einer benutzerdefinierten Routine abgeglichen wurde. Daher hat ein benutzerdefiniertes Modul Vorrang vor einer integrierten Routine desselben Namens.
Jedes Broker-Schema besitzt ein eindeutiges Symbol oder Namespace für eine Routine, so dass ein Routinename eindeutig ist, wenn er von dem Namen des Schemas angegeben wird, dem er angehört.
CALL myProc1() INTO cursor; CALL myProc1() INTO OutputRoot.XML.TestValue1;
Die CALL-Anweisung übergibt die Parameter in der angegebenen Reihenfolge an die Prozedur. Parameter, die in der Routinendefinition als IN oder INOUT festgelegt sind, werden vor Ausführung der CALL-Anweisung bewertet. Parameter, die als OUT definiert wurden, werden jedoch stets als NULL-Parameter des richtigen Typs eingegeben. Wenn die Prozedur vollständig ausgeführt wurde, werden alle Parameter aktualisiert, die als OUT oder INOUT deklariert wurden, um alle Änderungen zu übernehmen, die bei der Ausführung der Prozedur an ihnen vorgenommen wurden. Als IN definierte Parameter werden während der Ausführung einer Prozedur nie geändert.
Routinenüberladung wird nicht unterstützt. Sie können also nicht zwei Routinen mit identischem Namen in demselben Brokerschema erstellen. Wenn der Broker eine überlappende Routine findet, wird eine Ausnahme ausgegeben. Gleichermaßen können Sie auch keine in einer Datenbank gespeicherte Prozedur aufrufen, die überladen wurde. Eine in einer Datenbank gespeicherte Prozedur ist überladen, wenn eine andere Prozedur mit identischem Namen im selben Datenbankschema existiert. Sie können jedoch eine überladene Java-Methode aufrufen, solange Sie eine separate ESQL-Definition für jede überladene Methode erstellen, die Sie aufrufen möchten, und jeder ESQL-Definition einen eindeutigen Namen geben.