EVAL ステートメントのパラメーターは、1 つの文字値です。それは、SQL ステートメントとして解釈されて処理されます。
EVAL 関数についての詳細は、EVAL 関数を参照してください。
EVAL は、式の形式のパラメーターを 1 つ必要とし、その式を評価して、結果値を文字ストリングにキャストします (既にそうなっているのでない限り)。 そのため、EVAL に渡される式は、文字ストリングで表せるものでなければなりません。
ユーザー定義のプロシージャーは EVAL ステートメント内で定義できませんが、EVAL を使用して、EVAL ステートメントが使用されている範囲にあるユーザー定義のプロシージャーを呼び出すことができます。
IF (FALSE) THEN CALL procedure(<parameters>); END IF;
前のコードでは、procedure() を、問題の名前付きプロシージャーに置き換える必要があることに注意してください。次の例では、A と B は整数スカラー変数で、scalarVar1 と OperatorAsString は文字ストリング・スカラー変数です。
式 A+B は整数値を戻しますが、整数値は文字ストリングとして表すことができるため、受け入れられます。必要なキャストは、EVAL が続けて第 2 段階の評価を行う前に実行されます。
最終のストリング・リテラルの最後にあるセミコロンは必要です。それは、EVAL が ESQL ステートメントの代わりに使われている場合は、その最初の段階の評価では、終端のセミコロンを含めて、有効な ESQL ステートメントを表すストリングを戻す必要があるためです。
EVAL ステートメントの内側で宣言される変数は、EVAL ステートメントの外側では使用できません。
EVAL の真の能力は、それを使用して ESQL のステートメントや式を動的に構成できることです。 例えば 2 番目と 3 番目の上記の例では、scalarVar1 または operatorAsString の値は、送られてくるメッセージ・フィールドの値、または他の動的な値に応じて設定され、長くなることがある IF-THEN の反復を必要とせずに、ESQL に処理させることを有効に制御することができます。
ただし、EVAL を使った場合のパフォーマンスへの影響を考慮してください。 動的構成およびステートメントや式の処理は、構成済みのものを単純に処理する場合よりも必然的に時間を要します。 パフォーマンスが非常に重要である場合は、より特定化した高速の ESQL を書くことが望ましいでしょう。
この例では、EVAL が、式ではなくフィールド参照を置き換えるために使われています。
この例では、EVAL に渡される (SELECT T.x FROM Database.y) は、文字ストリングとして表せないリストを戻します。
SET OutputRoot.XMLNS.Data.Result[]
= EVAL('(SELECT T.x FROM Database.y AS T)');
EVAL ステートメントでのみ参照され、ESQL モジュールの残りの部分では参照されない関数は、BAR ファイルに含まれない可能性があります。 以下の例では、ESQL モジュール内のどこか他の場所で関数 MyFunction を参照する必要があります。そうしない場合、BAR ファイルのデプロイが失敗する可能性があります。
EVAL('CALL MyFunction(parm1, parm2);');
DECLARE functionName CHARACTER 'Function';
DECLARE callStmt CHARACTER 'CALL My' || functionName || '(parm1, parm2);';
EVAL(callStmt);