COLLECT allows you to create unique or summarized datasets. The
system first tries to find a table entry corresponding to the table
key. The key values are taken either from the header line of the
internal table itab, or from the explicitly-specified work
If the system finds an entry, the numeric fields that are not part
of the table key (see ABAP number types) are added to the
sum total of the existing entries. If it does not find an entry,
the system creates a new entry instead.
The way in which the system finds the entries depends on the
type of the internal table:
The system creates a temporary hash administration for the table to
find the entries. This means that the runtime required to find them
does not depend on the number of table entries. The administration
is temporary, since it is invalidated by operations like DELETE,
INSERT, MODIFY, SORT, ...). A subsequent COLLECT is then no longer
independent of the table size, because the system has to use a
linear search to find entries. For this reason, you should only use
COLLECT to fill standard tables. U
The system uses a binary search to find the entries. There is a
logarithmic relationship between the number of table entries and
the search time.
The system uses the internal hash administration of the table to
find records. Since (unlike standard tables), this remains intact
even after table modification operations, the search time is always
dependent on the number of table entries.
For standard tables and SORTED TABLEs, the system field
SY-TABIX contains the number of the existing or
newly-added table entry after the APPEND. With HASHED TABLEs,
SY-TABIX is set to 0.
COLLECT allows you to create a unique or summarized dataset, and
you should only use it when this is necessary. If neither of these
characteristics are required, or where the nature of the table in
the application means that it is impossible for duplicate entries
to occur, you should use INSERT
[wa INTO] TABLE itab instead of COLLECT. If you do
need the table to be unique or summarized, COLLECT is the most
efficient way to achieve it.
If you use COLLECT with a work area, the work area must be
compatible with the line type of the internal table.
Any components that do not form part of the key must have a
numeric type (see ABAP numeric types)
If you edit a standard table using COLLECT, you should only use
the COLLECT or MODIFY
... TRANSPORTING f1 f2 ... statements (where none of
f1, f2, ... may be in the key) enthalten sein). Only then can you
be sure that:
- The internal table actually is unique or summarized
- COLLECT runs efficiently. The check whether the
already contains an entry with the same key has a constant
search time (hash procedure).
If you use any other table modification statements, the check for
entries in the dataset with the same key can only run using a
linear search (and will accordingly take longer). You can use the
function module ABL_TABLE_HASH_STATE to test whether the
COLLECT has a constant or linear search time for a given standard
TYPES: BEGIN OF COMPANY,
NAME(20) TYPE C,
SALES TYPE I,
END OF COMPANY.
DATA: COMP TYPE COMPANY,
COMPTAB TYPE HASHED TABLE OF COMPANY
WITH UNIQUE KEY NAME.
COMP-NAME = 'Duck'. COMP-SALES = 10. COLLECT COMP INTO COMPTAB.
COMP-NAME = 'Tiger'. COMP-SALES = 20. COLLECT COMP INTO COMPTAB.
COMP-NAME = 'Duck'. COMP-SALES = 30. COLLECT COMP INTO COMPTAB.
Table COMPTAB now has the following contents:
NAME | SALES --------------- Duck | 40 Tiger | 20
COLLECT ... SORTED BY f is obsolete, and should no longer be
used. It only applies to standard tables, and has the same function
... SORTED BY f , which you should use instead.
The runtime of a COLLECT increases with the width of the table
key and the number of numeric fields whose contents are
COLLECT_OVERFLOW: Overflow in an integer field during
COLLECT_OVERFLOW_TYPE_P: Overflow in a type P field during
TABLE_COLLECT_CHAR_IN_FUNCTION: COLLECT on a non-numeric