AS ABAP Release 758, ©Copyright 2024 SAP SE. All rights reserved.

ABAP - Keyword Documentation →  ABAP - ABAP Release News →  News for ABAP Release 7.0 and its EhPs →  News for ABAP Release 7.0, EhP2 → 

Internal Tables in ABAP Release 7.0, EhP2

1. Dynamic WHERE Condition

2. Definition of Secondary Table Keys

3. Using Secondary Keys

4. Updating Secondary Keys

5. Streaming for Internal Tables

Modification 1  

Dynamic WHERE Condition

From ABAP release 7.0, EhP2, the statements LOOP AT itab, MODIFY itab, and DELETE itab make it possible to specify the WHERE condition in a cond_syntax data object dynamically.

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.

From ABAP 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 ABAP 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 are part of the technical type properties of an internal table. Secondary keys can be specified generically for standalone table types.

Modification 3  

Using Secondary Keys

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

• WITH [TABLE] KEY keyname COMPONENTS ...
• USING KEY keyname

keyname can be used 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 used can now also be specified explicitly using a table key when indexes are specified. The system field sy-tabix is now filled with reference to the table index used. It is set to 0 for access using a hash key.

The enhanced statements are:

• READ TABLE itab

  The lines to be read can be specified using a secondary key.

• LOOP AT itab

  The processing sequence and conditions can be controlled using a secondary table key.

• INSERT itab

  Only a secondary key for the source table can be specified here, from which multiple lines are copied. The position they are inserted at is determined solely using the primary key and the primary index.

• APPEND

  Only a secondary key for the source table can be specified here, onto which multiple lines are appended.

• MODIFY itab

  The lines to be modified can be specified using a secondary key.

• DELETE itab

  The lines to be deleted can be specified using a secondary key.

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:

• In inserting operations, such as INSERT or APPEND, and in change operations using MODIFY, the secondary table key administration of unique keys is updated immediately (direct update), while for non-unique table keys it is updated upon the next explicit use of the secondary table key (lazy update). If an update infringes the uniqueness of a secondary key, an exception is raised immediately.
• For block operations, such as statements between internal tables, or when internal tables are filled using SELECT, the behavior is the same as with inserting operations.
• When individual lines are modified using field symbols or data references that point to table lines, the secondary key administration of unique keys is updated upon the next access to the internal table (delayed update), and the secondary key administration of non-unique keys is updated upon the next explicit use of the secondary table key (lazy update). A uniqueness check is also run when the update is made. An internal table might therefore be in an inconsistent state with respect to the secondary key after individual lines are modified. An exception is not raised until the table is next used.

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.