CALL문은 루틴을 호출합니다.
호출된 루틴은 정의와 일치하는 방식으로 호출되어야 합니다. 예를 들면, 루틴이 처음 두 개의 정수 유형과 세 번째의 문자 유형으로 된 세 개의 매개변수로 정의된 경우 CALL문은 각 데이터 유형이 정의와 일치하는 세 개의 변수를 루틴에 전달해야 합니다. 이것은 정확한 서명 일치라고 하며, CALL문에서 제공한 서명이 루틴 정의에서 제공한 서명과 일치해야 함을 의미합니다.
정확한 서명 일치는 루틴의 리턴 값에도 적용됩니다. CREATE FUNCTION문에 RETURNS절을 지정하거나 루틴이 내장 함수인 경우 CALL문에서 INTO 절을 지정해야 합니다. 루틴에서의 리턴 값은 무시할 수 없습니다. 반대로 CREATE FUNCTION 문에 RETURNS 절을 지정하지 않은 경우에는 루틴에서의 리턴 값이 없으므로 INTO 절도 지정하지 말아야 합니다.
이러한 다양한 구현은 CALL 구문 다이어그램의 일부 절이 모든 루틴 유형에 적용되지 않음을 의미합니다. 또한 CALL문이 루틴이 정의된 방법과 상관 없이 루틴의 유형을 호출할 수 있습니다.
선택적 BrokerSchemaName 매개변수가 지정되지 않은 경우 브로커 SQL 구문 분석기는 PATH 문에서 설명한 알고리즘을 사용하여 이름 지정된 프로시저를 검색합니다(BROKER SCHEMA 문의 PATH절 참조).
BrokerSchemaName 매개변수가 지정된 경우 브로커 SQL 구문 분석기는 먼저 경로를 검색하지 않고 지정된 스키마에서 이름 지정된 프로시저를 호출합니다. 그러나 프로시저 참조가 모호하고(즉, 서로 다른 브로커 스키마에 동일한 이름의 프로시저가 두 개인 경우) 참조가 선택적 BrokerSchemaName에 의해 규정되지 않은 경우 Eclipse 도구 세트는 모호한 코드를 전개하기 위해 사용자가 정정해야 하는 "타스크 보기 오류"를 생성합니다.
브로커 제공 내장 함수는 SQL이라고 하는 사전정의된 브로커 스키마에 자동적으로 배치되었습니다. SQL 스키마는 사용자 정의 루틴과 일치하지 않는 루틴에 대해 항상 마지막으로 검색됩니다. 따라서 사용자 정의 모듈은 동일한 이름의 내장 루틴보다 우선순위를 가집니다.
각 브로커 스키마는 루틴에 대해 고유한 기호 또는 네임스페이스를 제공하므로 루틴이 속하는 스키마의 이름으로 규정되는 경우 루틴 이름이 고유합니다.
CALL myProc1() INTO cursor; CALL myProc1() INTO OutputRoot.XML.TestValue1;
CALL문은 주어진 순서대로 프로시저에 매개변수를 전달합니다. 루틴 정의에서 IN 또는 INOUT으로 정의된 매개변수는 CALL이 작성되기 전에 평가되지만 OUT으로 정의된 매개변수는 항상 올바른 유형의 NULL 매개변수로 전달됩니다. 프로시저가 완료되면 OUT 또는 INOUT으로 선언된 매개변수는 프로시저의 실행 중 변경된 사항을 반영하여 갱신됩니다. IN으로 정의된 매개변수는 프로시저의 실행 중 전혀 변경되지 않습니다.
루틴 오버로딩은 지원되지 않습니다. 즉, 동일한 브로커 스키마에서 동일한 이름이 있는 두 개의 루틴을 작성할 수 없습니다. 루틴이 과부하 상태임을 브로커가 감지할 경우 예외가 발생합니다. 마찬가지로 과부하 상태의 데이터베이스 저장 프로시저를 호출할 수 없습니다. 동일한 이름의 다른 프로시저가 동일한 데이터베이스 스키마에 있는 경우 데이터베이스 저장 프로시저가 과부하 상태가 됩니다. 그러나 호출하려는 각 과부하 메소드에 별도의 ESQL 정의를 작성하고 각 ESQL 정의에 고유의 루틴 이름을 제공하는 경우 과부하 상태의 Java 메소드를 호출할 수 있습니다.