ABAP Keyword Documentation → ABAP − Reference → Processing External Data → ABAP Database Access → ABAP SQL → ABAP SQL - Operands and Expressions → ABAP SQL - SQL Conditions sql_cond → sql_cond - rel_exp for Statements
sql_cond - (cond_syntax)
Other versions: 7.31 | 7.40 | 7.54
Syntax
... (cond_syntax) ...
Effect
A relational expression can be specified dynamically as a parenthesized data object cond_syntax
that contains the syntax of a logical expression sql_cond
valid here or is initial when the statement is executed. The result of the relational expression
(cond_syntax) is determined by the result of the contained logical expression. If cond_syntax
is initial when the statement is executed, the relational expression is true.
The data object cond_syntax
can be a character-like data object or a
standard table with
a character-like row type. The syntax in cond_syntax
is not case-sensitive
(as in the static syntax). When specifying an internal table, you can distribute the syntax over multiple rows. Invalid syntax raises a handleable exception from the class CX_SY_DYNAMIC_OSQL_ERROR.
The logical expression in cond_syntax
can be joined using AND
or OR
or negated using NOT
and a dynamic logical
expression (cond_syntax)
can be specified as a single relational expression of a composite logical expression.
Host expressions are not allowed in dynamic logical expressions.
If a dynamic SQL condition (cond_syntax)
is used for a read, the content of cond_syntax
is evaluated once for each
query. Any changes made to the
content of cond_syntax
in a SELECT
loop or WITH
loop are ignored by the relational expression.
Security Note
If used wrongly, dynamic programming techniques can present a serious security risk. Any dynamic content
that is passed to a program from the outside must be checked thoroughly or escaped before being used
in dynamic statements. This can be done using the system class CL_ABAP_DYN_PRG or the predefined function escape
. See
SQL Injections Using Dynamic Tokens.
Notes
- It is also possible to evaluate an internal table specified after the addition
FOR ALL ENTRIES
of a main query in a relational expression.
- It is possible to check a ranges table in a dynamic relational expression.
- If
cond_syntax
is an internal table with a header line, the table body is evaluated, and not the header line.
- Dynamic relational expressions can also be created interactively using dynamic selections.
- When a condition is specified dynamically, the syntax check can take place only at runtime. Therefore, specifying a relational expression at runtime needs more execution time than a corresponding expression specified in the program text.
- The data objects specified in a dynamic condition should be declared in the same context, if possible, since searches in higher contexts at runtime are more unwieldy.
- The class CL_ABAP_DYN_PRG contains methods that make it possible to create correct and secure dynamic SQL conditions.
- The literals of the dynamically specified ABAP SQL statements can span multiple rows of a token specified dynamically as an internal table.
- When specified dynamically, ABAP SQL statements can contain the comment characters
*
and"
as follows:
- In a dynamic token specified as a character-like data object, all content is ignored from the first comment character
"
.
- In a dynamic token specified as an internal table, all rows are ignored that start with the comment
character
*
. In the row, all content is ignored from the first comment character"
.
- In dynamic SQL conditions, static attributes or constants of a class cannot be accessed from outside in cases where the class has a static constructor and the constructor was not yet executed.
- When a subquery is specified dynamically, the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check.
Example
Creates a dynamic comparison from user input. In the case of incorrect syntax or incorrect semantics, exceptions are raised that are handled using the common superclass. Any
SQL injections are prevented
by checks made on the entered column name. If this were not the case, a user could, for example, enter
"CARRID <> value OR CARRID" in the field column
,
producing a condition "CARRID <> value OR CARRID = value", which would be true regardless of the entry made in the field value
.
DATA: column TYPE c LENGTH 30,
value TYPE c LENGTH 30.
cl_demo_input=>new(
)->add_field( CHANGING field = column
)->add_field( CHANGING field = value )->request( ).
TRY.
cl_abap_dyn_prg=>check_column_name( column ).
CATCH cx_abap_invalid_name.
cl_demo_output=>display( 'Invalid column name' ).
RETURN.
ENDTRY.
DATA(cond_syntax) = column && ` = @value`.
TRY.
SELECT *
FROM spfli
WHERE (cond_syntax)
INTO TABLE @DATA(spfli_tab).
CATCH cx_sy_dynamic_osql_error.
cl_demo_output=>display( `Wrong WHERE condition!` ).
ENDTRY.
Example
Creating a dynamic WHERE
condition by chaining user input as shown below is even more risky than the previous example. Any
SQL injections must be
prevented by transforming quotation marks in the entry value
. A user can,
for example, enter "CARRID" in column
and
"LH' OR CARRID <> 'LH" in value
, which would produce the condition
"CARRID = 'LH' OR CARRID <> 'LH'" (always true) if the quotation marks
were not transformed. Once applied, the method QUOTE of the class CL_ABAP_DYN_PRG,
which also adds quotation marks at the beginning and end, produces the condition "CARRID = 'LH'' OR CARRID <> ''LH'". The handling of consecutive quotation marks in
text field literals results in the column CARRID being compared precisely with the entered value, making the result of the condition always false.
DATA: column TYPE c LENGTH 30,
value TYPE c LENGTH 30.
cl_demo_input=>new(
)->add_field( CHANGING field = column
)->add_field( CHANGING field = value )->request( ).
TRY.
cl_abap_dyn_prg=>check_column_name( column ).
CATCH cx_abap_invalid_name.
cl_demo_output=>display( 'Invalid column name' ).
RETURN.
ENDTRY.
DATA(cond_syntax) = column && ` = ` && cl_abap_dyn_prg=>quote( value ).
TRY.
SELECT *
FROM spfli
WHERE (cond_syntax)
INTO TABLE @DATA(spfli_tab).
CATCH cx_sy_dynamic_osql_error.
cl_demo_output=>display( `Wrong WHERE condition!` ).
ENDTRY.