ARTICLE
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.
Example
The example of Deletion Using Table
Keys demonstrates the runtimes that are required to create the
secondary key and when they occur.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved