Skip to content

ABAP Keyword Documentation →  ABAP - Release-Specific Changes →  Changes in Release 7.40 and Its SPs →  Changes in Release 7.40, SP08 

ABAP SQL in Release 7.40, SP08


1. New column data_source~* specified after SELECT


2. Inline declarations for the target area of SELECT


3. SQL expressions


4. Reads on CDS views with parameters


5. Restrictions removed


6. Arrangement of the INTO clause


7. Stricter checks for syntax rules


8. Strict mode in the syntax check


9. Comparable types

Other versions: 7.31 | 7.40 | 7.54

Modification 1

New Column dbtab~* Specified After SELECT

In the definition of the results set in the SELECT list of a SELECT statement, data_source~ can be specified as an element of the SELECT list from Release 7.40, SP08 to include all columns of different database tables or views used after FROM in the results set. If specified, data_source~ can be combined with individual specified columns col_spec (with the exception of aggregate expressions).

When data_source~* is specified in the results set, the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check.

Modification 2

Inline Declarations for the Target Area of SELECT

After the addition INTO of a SELECT statement, inline declarations can be made from Release 7.40, SP08 using the declaration operator DATA(...) with the prefixed escape character @. Inline declarations can be made for individual parenthesized data objects (@DATA(elem1),@DATA(elem2),...), for individual work areas INTO @DATA(wa), and for internal tables INTO TABLE @DATA(itab). Either an elementary data object, a structure, or an internal table is declared depending on the results set defined in the SELECT list and the database tables used after FROM.

When inline declarations are used, the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check.

Modification 3

SQL Expressions

The SQL expressions introduced in Release 7.40, SP05 were revised in the following ways:

  • The operator CASE can now be used to perform complex case distinctions (searched case) as well as simple case distinctions.
  • SQL expressions can be specified after GROUP BY.
  • SQL expressions can be specified together with aggregate expressions in the SELECT list.
  • SQL expressions can be specified as arguments of aggregate functions (except avg) in the SELECT list and the HAVING clause.

If one of the new features is used, the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check.

Modification 4

Reads on CDS Views with Parameters

From Release 7.40, SP08, CDS views can be defined with input parameters that are assigned actual parameters when used. To enable this, the option of a parenthesized comma-separated list for parameter passing was added to the data source specified in the statement SELECT:

( pname1 = act1, pname1 = act2, ...)

Since not all database systems support views with parameters, the new class CL_ABAP_DBFEATURES with the method USE_FEATURES is available, which detects whether this is possible for the current database system. Furthermore, accessing a view with parameters triggers a warning from the syntax check; this warning can be hidden by a pragma.

Modification 5

Restrictions Removed

The following previous restrictions were removed:

  • From Release 7.40, SP08, a negative sign - can be placed in front of an operand of an arithmetic expression that does not follow an arithmetic operator directly.
  • From Release 7.40, SP08, an operand operand1, operand2, ... in a simple case distinction can now also be an SQL expression.
  • From Release 7.40, SP08, the operators LIKE and IN (...) can be used in ON conditions.
  • From Release 7.40, SP08, individual comparisons can be joined using OR and negated using NOT.
  • From Release 7.40, SP08, outer joins no longer need to contain at least one comparison between columns on the left and right side.
  • Subqueries can now also be specified dynamically.

When one of the rule changes is exploited, the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check.

Modification 6

Arrangement of the INTO Clause

From Release 7.40, SP08, the INTO clause can and should be specified as the final clause of a SELECT statement. In this case, the additions UP TO, OFFSET and abap_options of the SELECT statement must be specified after INTO.

If the INTO clause is specified as the final clause, the syntax check is performed in a strict mode. This handles the statement more strictly than the regular syntax check.

Modification 7

Stricter Checks on Syntax Rules

From Release 7.40, SP08, the following syntax constructs that have always contained errors now produce syntax errors or runtime errors.

  • Correction for the WHERE Condition
Any columns that are specified in a HAVING clause outside of an aggregate expression must also be specified after GROUP BY. Before Release 7.40, SP08, this was not recorded by the static syntax check, but did raise a catchable exception. From Release 7.40, SP08, this produces a syntax check warning and raises a non-handleable exception outside of the strict mode of the syntax check.

Example

From Release 7.40, SP08, a syntax warning and non-handleable exception for:

DATA itab TYPE TABLE OF scarr.
SELECT *
       FROM scarr
       INTO TABLE itab
       HAVING carrid = 'LH'.

Modification 8

Strict Mode in the Syntax Check

If one the new features listed here is used in an ABAP SQL statement, the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check.

Modification 9

Comparable Types

A table of comparable types was constructed for comparisons performed on the database. The results of comparisons made between non-comparable types are determined by the database system and produce a syntax error (in the strict mode of the syntax check) or a syntax warning.