WebSphere Message Brokers
File: ak05020_
Writer: Bill Oppenheimer

Reference topic

This build: July 31, 2007 21:31:29

EVAL statement

The EVAL statement takes a character value, interprets it as an SQL statement, and processes it.

The EVAL function (also described here) takes a character value, but interprets it as an ESQL expression that returns a value.

Note: User defined functions and procedures cannot be defined within an EVAL statement or EVAL function.

Syntax

EVAL takes one parameter in the form of an expression, evaluates this expression, and casts the resulting value to a character string if it is not one already. The expression that is passed to EVAL must therefore be able to be represented as a character string.

After this first stage evaluation is complete, the behavior of EVAL depends on whether it is being used as a complete ESQL statement, or in place of an expression that forms part of an ESQL statement:
  • If it is a complete ESQL statement, the character string derived from the first stage evaluation is executed as if it were an ESQL statement.
  • If it is an expression that forms part of an ESQL statement, the character string is evaluated as if it were an ESQL expression and EVAL returns the result.

In the following examples, A and B are integer scalar variables, and scalarVar1 and OperatorAsString are character string scalar variables.

The following examples are valid uses of EVAL:
  • SET OutputRoot.XMLNS.Data.Result = EVAL(A+B);

    The expression A+B is acceptable because, although it returns an integer value, integer values are representable as character strings, and the necessary cast is performed before EVAL continues with its second stage of evaluation.

  • SET OutputRoot.XMLNS.Data.Result = EVAL('A' || operatorAsString || 'B');
  • EVAL('SET ' || scalarVar1 || ' = 2;');

    The semicolon included at the end of the final string literal is necessary, because if EVAL is being used in place of an ESQL statement, its first stage evaluation must return a string that represents a valid ESQL statement, including the terminating semicolon.

Variables declared within an EVAL statement do not exist outside that EVAL statement. In this way EVAL is similar to a function, in which locally-declared variables are local only, and go out of scope when the function is exited.

The real power of EVAL is that it allows you to dynamically construct ESQL statements or expressions. In the second and third examples above, the value of scalarVar1 or operatorAsString can be set according to the value of an incoming message field, or other dynamic value, allowing you to effectively control what ESQL is executed without requiring a potentially lengthy IF THEN ladder.

However, consider the performance implications in using EVAL. Dynamic construction and execution of statements or expressions is necessarily more time-consuming than simply executing pre-constructed ones. If performance is vital, you might prefer to write more specific, but faster, ESQL.

The following are not valid uses of EVAL:
  • SET EVAL(scalarVar1) = 2;

    In this example, EVAL is being used to replace a field reference, not an expression.

  • SET OutputRoot.XMLNS.Data.Result[] = EVAL((SELECT T.x FROM Database.y AS T));

    In this example, the (SELECT T.x FROM Database.y) passed to EVAL returns a list, which is not representable as a character string.

The following example is acceptable because (SELECT T.x FROM Database.y AS T) is a character string literal, not an expression in itself, and therefore is representable as a character string.
SET OutputRoot.XMLNS.Data.Result[]
 = EVAL('(SELECT T.x FROM Database.y AS T)');
Related concepts
ESQL overview
Related tasks
Developing ESQL
Related reference
Syntax diagrams: available types
ESQL statements
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:31:29

ak05020_ This topic's URL is: