ABAP - Keyword Documentation →  ABAP - Reference →  Processing External Data →  ABAP Database Accesses →  Open SQL →  Open SQL - Reads →  SELECT clauses →  SELECT - WHERE →  WHERE - sql_cond → 

Quick Reference

sql_cond - (cond_syntax)

Syntax

... (cond_syntax) ...

Effect

A logical expression can be specified as a parenthesized data object cond_syntax that contains the syntax of a logical expression (with the exception of host expressions) or is initial when the statement is executed. All logical expressions can be specified dynamically in this way.

The logical expression in cond_syntax can also be combined using AND or OR or negated using NOT. 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, as in ABAP Editor, not case-sensitive. When an internal table is specified, the syntax can be distributed across multiple rows.

The result of the logical expression (cond_syntax) is determined by the result of the contained logical expression. If cond_syntax is initial when the statement is executed, the logical expression is true.

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

Comment characters placed within literals are, however, part of the literal.

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.

PARAMETERS: column   TYPE c LENGTH 30,
            value  TYPE c LENGTH 30.

DATA: spfli_tab TYPE TABLE OF spfli,
      cond_syntax TYPE string.

AT SELECTION-SCREEN.
  TRY.
      cl_abap_dyn_prg=>check_column_name( column ).
    CATCH cx_abap_invalid_name.
      MESSAGE 'Not allowed' TYPE 'E'.
  ENDTRY.

START-OF-SELECTION.

  cond_syntax = column &&  ` = @value`.

  TRY.
      SELECT *
             FROM spfli
             WHERE (cond_syntax)
             INTO TABLE @spfli_tab.
    CATCH cx_sy_dynamic_osql_error.
      MESSAGE `Wrong WHERE condition!` TYPE 'I'.
  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.

PARAMETERS: column   TYPE c LENGTH 30,
            value  TYPE c LENGTH 30.

AT SELECTION-SCREEN.
  TRY.
      cl_abap_dyn_prg=>check_column_name( column ).
    CATCH cx_abap_invalid_name.
      MESSAGE 'Not allowed' TYPE 'E'.
  ENDTRY.

START-OF-SELECTION.

  value = cl_abap_dyn_prg=>quote( value ).
  DATA(cond_syntax) = column && ` = ` && value.

  TRY.
      SELECT *
             FROM spfli
             WHERE (cond_syntax)
             INTO TABLE @DATA(spfli_tab).
    CATCH cx_sy_dynamic_osql_error.
      MESSAGE `Wrong WHERE condition!` TYPE 'I'.
  ENDTRY.