Skip to content

ABAP Keyword Documentation →  ABAP - Release-Specific Changes →  Changes in Release 7.40 →  Changes in Release 7.40, SP02 

Internal Tables in Release 7.40, SP02


1. Table expressions


2. Predefined functions for internal tables


3. Explicit definition of an empty key


4. Table sharing for boxed components


5. References in specified components


6. WHERE condition optimized


7. Expression for dynamic sorts

Other versions: 7.31 | 7.40 | 7.54

Modification 1

Table Expressions

The new table expressions permit reads to be performed on internal tables in operand positions.

Modification 2

Predefined Functions for Internal Tables

  • The table function line_index can be used to identify a row number in an index of an internal table and use it in operand positions.
  • The predicate function line_exists can be used to check the existence of table rows; the resulting logical value can then be used directly.

Modification 3

Explicit Definition of an Empty Key

The new addition EMPTY KEY of the statements TYPES, DATA, and so on can be used to define an empty table key explicitly for standard tables. Without this addition, empty table keys occur only if the standard key of a standard table does not contain any components suitable as key fields.

Modification 4

Table Sharing for Boxed Components

Until now there was no table sharing if the row types contained boxed components. This restriction has now been lifted.

Modification 5

References in Dynamically Specified Components

Object component selectors can now be specified when components are specified dynamically (this was not previously the case). However, those specifications can be made that are statically possible. For example, when using ASSIGN attributes cannot be accessed that are not known statically. This is the case, for example, when using superclass references to access subclass components.

Modification 6

WHERE Condition Optimized

The rules described under Optimization of the WHERE Condition have been modified as follows:

  • Except in comparisons for equality, optimizations are now also performed for the predicate expression IS INITIAL. This enables a simple check to be made on the initial value, in particular for columns typed as reference variables. A static WHERE condition cannot contain any duplicate or overlapping specified keys, if the prerequisites for optimizations are met. This means that this change is occasionally incompatible: Syntax errors are now produced in those WHERE conditions in which a key column is checked using both a comparison for equality with one value and using IS INITIAL.
  • Syntax warnings are no longer produced by mistake for non-optimizable type combinations in comparisons, even if the comparison does not contain any key columns. Non-optimizable type combinations now produce syntax warnings only if they actually modify key fields of a hash key or of the initial part of a sorted key. The syntax warnings have been improved so that the non-optimizable combination is mentioned in the text.
  • The following type combinations were not previously detected as non-optimizable when secondary keys were used in comparisons:
  • string with n, i ( b, s), f, decfloat16, and decfloat34
  • xstring with c and string
There was no syntax error or exception in these cases. Instead, all rows of the internal table were checked linearly when the statement was executed or reads performed using the primary key. Optimized reads are guaranteed when using secondary keys, which is why the combinations above now produce syntax errors or raise exceptions. This represents an incompatible change.

Modification 7

Expression for Dynamic Sorts

In the statement SORT itab, the table (otab) can now be specified for dynamic sorts as the result of an expression or functional method call.