SAP WHERE LOGEXP COMPARE Get Example source ABAP code based on a different SAP tableSAP Help
Short Reference ABAP_SQLCOND - Comparison Operators ABAP_SYNTAX ... operand1 operator operand2 $[ALL$|ANY$|SOME$] ( SELECT subquery_clauses )$} ... What does it do? operand1 in accordance with the comparison operator operator with the content of the operand operand2 or with the result of a scalar subquery. The following can be specified for operand1 on the left 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. untyped literal, a host variable, or a host expression must match the data type of operand1 in accordance with the rules for lossless assignments. strict modes of the syntax check from ABAP_RELEASE ABAP_740_SP08 and can raise an exception. Built-in SQL functions and cast expressions. Aggregate expressions in a HAVING clause. operatorMeaning =, EQTrue if the content of operand1 is equal to the content of operand2. <>, NETrue if the content of operand1 is not equal to the content of operand2. < , LTTrue if the content of operand1 is less than the content of operand2. >, GTTrue if the content of operand1 is greater than the content of operand2. < =, LETrue if the content of operand1 is less than or equal to the content of operand2. >=, GETrue if the content of operand1 is greater than or equal to the content of operand2. If operand2 is an untyped 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 the ABAP Dictionary before the statement is passed to the database. Comparisons between columns or between SQL expressions (including typed literals and aggregate expressions) and columns are performed completely 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, where fewer conversions are generally possible here than in ABAP. The platform-dependent behavior can produce different results or even SQL errors on individual platforms. For details on the conversion rules of SAP HANA Platform, see the SAP HANA SQL Reference Guide. The decimal places are respected in comparisons between numeric types. In greater than or less than comparisons with character-like types, the result can depend on the code page used by the database system. This applies in 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 depends on the platform 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 depends on the platform and buffering. More specifically, a single blank in the SAP HANA database and in MaxDB is not found in the interval of all possible characters. Latest notes: 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. The obsolete forms > < , = < , and => of comparison operators may still appear outside of classes. ABAP_EXAMPLE_VX5 ABAP_EXAMPLE_VX5
