ABAP SQL - SQL Operands sql_elem
These elementary operands can have the following properties:
- They can be specified as elementary SQL expressions in all operand positions in which SQL expressions are possible.
- They can also occur in specific operand positions in which no SQL expressions are possible.
The relevant rules apply in operand positions in which host variables are handled like SQL expressions. The rules of the position in question apply in operand positions in which no SQL expressions are possible.
The value of a column
col is determined on the database, but the values of
literals, host variables, and host expressions are passed to the database system by ABAP before the
SQL statement is executed (or fetched by the database system after it is executed). The operand position determines how the value of an ABAP object like this is handled:
- An ABAP object specified as an elementary SQL expression in a read position is mapped (as described here) to a dictionary type, passed to the database as this type, and handled accordingly. The database rules apply.
- In operand positions in which an ABAP objects is not handled as an SQL expression, a conversion (using the ABAP conversion rules) between the types in question takes place if required. This also covers any mappings from ABAP Dictionary types to ABAP types. If a literal, host variable, or a host expression is read, conversions are subject to the rules for lossless assignments. If the assignment cannot be lossless, an exception is raised. Literals and host constants produce, depending on the syntax check mode, syntax warnings or syntax errors.
SQL expressions are possible on the left side of the
condition. The specified column
carrid can be placed in parentheses as an
elementary SQL expression. No SQL expressions are possible on the right side of the condition. The literal
'UA' cannot be set in parentheses.
SELECT * FROM scarr WHERE ( carrid ) = 'UA' INTO TABLE @DATA(itab).
In the first
SELECT statement, the host variable
@field is in an
operand position in which it is not handled as an elementary SQL expression. Their content must comply with the
rules for lossless assignments, which is not the case
here. This is why an exception of the class CX_SY_OPEN_SQL_DATA_ERROR is raised. In the second
SELECTstatement, the same host variable is in an
operand position in which it is evaluated as an elementary SQL expression. Also, a
mapping is made to a dictionary type and the value is evaluated using this type on the database. No exception is raised in this case.
DATA field TYPE c LENGTH 100 VALUE 'XXXXXXXXXXXXXXX'. TRY. SELECT * FROM scarr WHERE carrid IN ( @field ) INTO TABLE @DATA(rtab1). CATCH cx_sy_open_sql_data_error. cl_demo_output=>write( 'Data loss in conversion' ). ENDTRY. TRY. SELECT * FROM scarr WHERE ( carrid, carrname ) IN ( ( @field, ' ' ) ) INTO TABLE @DATA(rtab2). CATCH cx_sy_open_sql_error. cl_demo_output=>write( 'Error in mapping' ). ENDTRY. cl_demo_output=>display( ).