ABAP Keyword Documentation →  ABAP − Release-Specific Changes →  Changes in Release 7.0, EhP2 → 

Internal Tables in Release 7.0, EhP2


1. Dynamic WHERE Condition


2. Definition of Secondary Table Keys


3. Use of Secondary Table Keys


4. Updating of Secondary Table Keys


5. Streaming for Internal Tables



Modification 1

Dynamic WHERE Condition

As of Release 7.0, EhP2, the LOOP AT itab, MODIFY itab, and DELETE itab statements allow you to dynamically specify the WHERE condition in a cond_syntax data object.



Modification 2

Definition of Secondary Table Keys

Previously, each internal table had just one table key. Any search key could be entered when accessing internal tables, but this was not very efficient. Also, standard tables were always searched linearly during key access. To be able to efficiently access an internal table with different keys, and to also allow efficient key access to standard tables, secondary table keys were introduced.

As of Release 7.0, EhP2, secondary table keys can be defined for internal tables with TYPES and DATA as well as in ABAP Dictionary. An internal table can have up to 15 secondary table keys with different names. At the same time, what was previously the table key became the primary table key, and a predefined name for it, primary_key, was introduced. This can be replaced with an alias name in the enhanced definition of the primary table key in Release 7.0, EhP2.

Secondary table keys can be hash keys or sorted keys. A secondary table index is created for each sorted secondary key of an internal table. The previous table index, which exists only for index tables, becomes the primary table index.

Secondary table keys belong to the technical type properties of an internal table. The specification of secondary keys can be generic for standalone table types.



Modification 3

Using Secondary Keys

The following additions have been introduced for statements that access rows of internal tables:

You can use keyname to specify the name of the key to be used statically or dynamically.

At the same time, statements that previously only accessed the primary key have been enhanced so that access to secondary keys is also possible. The table index to be used can now also be explicitly specified with a table key in index specifications. The sy-tabix system field is now filled with reference to the table index used. It is set to 0 for access via a hash key.

The enhanced statements are:

In statements where these additions have not been introduced, such as SORT, COLLECT, or PROVIDE, secondary keys are not explicitly supported.



Modification 4

Updating Secondary Keys

In all statements that change the content or structure of an internal table, the internal administration of the secondary table key (hash administration or secondary table index) is updated automatically as follows:

Class CL_ABAP_ITAB_UTILITIES contains methods that can be used to update single secondary keys or all secondary keys for an internal table in exceptional situations.



Modification 5

Streaming for internal tables

The new streaming concept supports internal tables.