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:

Any SQL expressions except aggregate expressions and window expressions

Aggregate expressions in a HAVING clause.

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

Any elementary SQL operands.

Here, a column col must be specified as data_source~comp, or tabalias~comp using the column selector and it must be possible to compare the data types of the left side and right side.

The content of an ABAP object (namely a literal, a host variable, or a host expression) must match the data type of operand1 in accordance with the rules for lossless assignments. This is checked by the strict modes of the syntax check from Release 7.40, SP08 and can raise an exception.

Aggregate expressions in a HAVING clause

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:

If operand2 is a literal, a host variable, or a host expression, the value is converted (if necessary) to the data type that matches the type of the operand operand1 in accordance with the ABAP conversion rules and the tables of built-in types in ABAP Dictionary before the statement is passed to the database.

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