Skip to content

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 - Relational Operators

Other versions: 7.31 | 7.40 | 7.54

Syntax


... operand1 operator operand2 
                    | {[ALL|ANY|SOME] ( SELECT subquery_clauses )} ...

Effect

This relational expression compares the content of the operand operand1 (in accordance with the relational operator operator) with the the content of the operand operand2 or with the result of a scalar subquery.

  • The following can be specified for operand1 on the right side:
  • The following can be specified for operand2 on the right side:

The following table shows the possible relational operators:

operator Meaning
=, EQ True if the content of operand1 is equal to the content of operand2.
<>, NE True if the content of operand1 is not equal to the content of operand2.
<, LT True if the content of operand1 is less than the content of operand2.
>, GT True if the content of operand1 is greater than the content of operand2.
<=, LE True if the content of operand1 is less than or equal to the content of operand2.
>=, GE True if the content of operand1 is greater than or equal to the content of operand2.

Note the following when using these operators:

  • Comparisons between columns or between SQL expressions or aggregate expressions and columns are performed in full on the database. No type conversions are made in ABAP beforehand. If the data types or lengths on the left and right side do not match, the resulting behavior depends entirely on the conversion rules of the database (however, fewer conversions are generally possible here than in ABAP). The platform-dependent behavior can produce different results or even SQL errors on individual platforms.
  • The decimal places are respected in comparisons between numeric types.
  • In greater than/less than comparisons with character-like types, the result can depend on the code page used by the database system. This applies to particular to the non-printable characters.
  • Trailing blanks are usually ignored in comparisons between character-like types.
  • In the case of columns that contain nothing but a blank character, it is the platform that determines how this blank is saved:
  • In the SAP HANA database and in MaxDB a single blank is saved as an empty string and not as specified by the code page in question.
  • In all other database and in table buffering, a single blank is saved in accordance with the code page.
This means that the behavior produced when a value of this type is selected using size comparisons is determined by the platform and by buffering. More specifically, a single blank in the SAP HANA database and in MaxDB is not found in the interval of all possible characters.


Notes

  • The obsolete forms ><, =<, and => of relational operators may still appear outside of classes.

  • Size comparisons for character-like operands should be avoided to prevent platform-dependent behavior. An exception here are simple cases, such as operands that contain only digits.

Example

Gets flights with a seat occupancy that is less than the entered value.

DATA seatsocc TYPE sflight-seatsocc. 
cl_demo_input=>request( CHANGING field = seatsocc ). 

SELECT carrid, connid, fldate 
       FROM sflight 
       WHERE seatsocc < @seatsocc 
       INTO TABLE @DATA(sflight_tab).

Example

Gets overbooked flights.

SELECT carrid, connid, fldate 
       FROM sflight 
       WHERE seatsocc > sflight~seatsmax 
       INTO TABLE @DATA(sflight_tab).

Continue

sql_cond - ALL, ANY, SOME

sql_cond - Comparable Types