CALL ステートメントはルーチンを呼び出し (起動し) ます。
呼び出されるルーチンは、そのルーチンの定義と一致する方法で起動しなければなりません。例えば、3 つのパラメーターを指定してルーチンを定義しており、そのうち初めの 2 つのタイプが integer で 3 つ目のタイプが character の場合、CALL ステートメントは 3 つの変数をルーチンに渡さなければならず、個々のデータ・タイプが定義と一致していなければなりません。このことを正確なシグニチャー・マッチング と呼び、CALL ステートメントによって提供されるシグニチャーとルーチンの定義によって提供されるシグニチャーが一致していなければならないという意味です。
正確なシグニチャー・マッチングは、ルーチンの戻り値にも適用されます。RETURNS 文節が CREATE FUNCTION ステートメント上に指定される場合やルーチンが組み込み関数の場合は、CALL ステートメントに INTO 文節を指定する必要があります。ルーチンからの戻り値は無視できません。逆に、RETURNS 文節が CREATE FUNCTION ステートメント上に指定されない場合、ルーチンからの戻り値はないので、INTO 文節を指定してはなりません。
インプリメンテーションにはこのような種類があるので、CALL 構文図の文節の中には、ルーチンのタイプによっては適用されない (または許可されない) ものがあります。また、CALL ステートメントは、ルーチンが定義されている方法に関係なく、どのタイプのルーチンでも起動できます。
オプションの BrokerSchemaName パラメーターが指定されていない場合、ブローカー SQL パーサーは PATH ステートメントに記述されているアルゴリズムを使用して名前付きプロシージャーを検索します (BROKER SCHEMA ステートメントの PATH 文節を参照してください)。
BrokerSchemaName パラメーターが指定されている場合、ブローカー SQL パーサーは、パスを先に検索せずに、指定されたスキーマ中の名前付きプロシージャーを起動します。しかし、プロシージャー参照があいまいで (つまり異なるブローカー・スキーマに同じ名前のプロシージャーが 2 つあり)、かつ参照がオプションの BrokerSchemaName で修飾されていない場合、Eclipse ツール・セットは "「タスク」ビュー・エラー" を生成します。あいまいなコードがデプロイされないように、このエラーを訂正する必要があります。
ブローカー提供の組み込み関数は、SQL という事前定義ブローカー・スキーマに自動的に置き換えられます。SQL スキーマ中でのユーザー定義ルーチンと一致していないルーチンの検索は、常に最後に行われます。したがって、ユーザー定義モジュールの方が、同じ名前の組み込みルーチンより優先されます。
個々のブローカー・スキーマは、ルーチンの固有のシンボルまたはネーム・スペースを提供します。したがって、ルーチンが属しているスキーマの名前でルーチン名が修飾されている場合、その名前は固有になります。
CALL myProc1() INTO cursor; CALL myProc1() INTO OutputRoot.XML.TestValue1;
CALL ステートメントはパラメーターを、指定された順序でプロシージャーに渡します。ルーチンの定義上で IN または INOUT として定義されたパラメーターは、CALL が実行される前に評価されますが、OUT として定義されたパラメーターは、常に適正なタイプの NULL パラメーターとして渡されます。プロシージャーが完了すると、OUT または INOUT として宣言されたパラメーターは、プロシージャーの実行中に行われた、それらに対する変更を反映するように更新されます。IN として定義されたパラメーターは、プロシージャーの実行の結果として変更されることは決してありません。
ルーチン多重定義はサポートされていません。したがって、同じブローカー・スキーマに、同じ名前のルーチンを 2 つ作成することはできません。ルーチンが多重定義であることをブローカーが検出すると、例外が生じます。同様に、多重定義されているデータベース・ストアード・プロシージャーを起動することはできません。同じデータベース・スキーマに同じ名前のプロシージャーが複数ある場合に、データベース・ストアード・プロシージャーは多重定義になります。しかし、呼び出したい多重定義メソッドごとに別々の ESQL 定義を作成し、個々の ESQL 定義に固有のルーチン名を付ければ、多重定義の Java メソッドを起動できます。