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
ABAP_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.
ABAP_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.
ABAP_MODIFICATION_3 Using Secondary Keys
The following additions have been introduced for statements that
access rows of internal tables:
WITH [TABLE] KEY keyname COMPONENTS ...
USING KEY keyname
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:
READ TABLE itab
The rows 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 rows 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 rows are appended.
MODIFY itab
The rows to be modified can be specified using a secondary key.
DELETE itab
The rows 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.
ABAP_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 rows are modified using using field symbols or data
references that point to table rows, 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 rows 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.
ABAP_MODIFICATION_5 Streaming for internal tables
The new streaming concept supports
internal tables .
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved