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
WITH KEY ... COMPONENTS(lazy update). If updating the administration causes a secondary key uniqueness violation, a handled exception or runtime error occurs.
APPENDand 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
- 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.
MODIFYis 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.
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.
The example of Deletion Using Table Keys demonstrates the runtimes that are required to create the secondary key and when they occur.