Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing Internal Data →  Internal Tables →  Internal Tables - Overview →  Table Keys →  Secondary Table Key 

Updating Secondary Keys

For all statements that change the content and structure of an internal table, the internal administration of the secondary keys is updated automatically as follows:

  • For all operations that insert rows into tables or delete rows from tables, the secondary key administration for unique keys is updated immediately. This means that a unique secondary key is up-to-date immediately after the operation (direct update). Non-unique secondary table keys are not updated immediately. Instead, they are updated when the secondary key is next used explicitly using USING KEY or WITH KEY ... COMPONENTS (lazy update). If updating the administration causes a secondary key uniqueness violation, a handled exception or runtime error occurs.
Inserting operations include table statements such as INSERT and APPEND and block operations for which the entire body of the table is filled at once, like for statements between internal tables, passing parameters to procedures, filling internal tables with SELECT, importing with IMPORT, and so on. The operation for deleting table rows is the DELETE table statement.
  • For operations that change the components of secondary table keys in existing rows, the secondary key administration is either updated directly or when a specified sychronization point is reached.
  • If MODIFY is used to modify individual rows, any unique secondary keys are updated directly (direct update). If the modification produces duplicate entries, an unhandleable exception is raised.
  • If field symbols or data references are used to modify individual rows, and these symbols or references point to table rows, then any unique secondary keys are updated the next time the internal table is accessed (delayed update). The uniqueness check also waits until the synchronization point is reached. An internal table can therefore be in an inconsistent state with respect to the secondary key following a modification to existing rows using field symbols or data references. The corresponding exception is only raised when the table is next used.
In both cases, a non-unique key not updated until the secondary table key is next used explicitly (lazy update).

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. These methods can be used for analysis and test purposes. It might also make sense to use them after making changes if the next access does not take place immediately afterwards in order to handle possible exceptions there and then.

Other versions: 7.31 | 7.40 | 7.54


Example

The example of Deletion Using Table Keys demonstrates the runtimes that are required to create the secondary key and when they occur.