0% found this document useful (0 votes)
307 views3 pages

Collect Statement of Internal Table

COLLECT allows you to create unique or summarized datasets from records in an internal table. It works by finding matching records based on the table key and adding numeric fields to the existing record. If no match is found, a new record is created. COLLECT is most efficient for hashed tables, where searching is independent of the number of records. It should only be used when uniqueness or summarization is required.

Uploaded by

Satish Namballa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
307 views3 pages

Collect Statement of Internal Table

COLLECT allows you to create unique or summarized datasets from records in an internal table. It works by finding matching records based on the table key and adding numeric fields to the existing record. If no match is found, a new record is created. COLLECT is most efficient for hashed tables, where searching is independent of the number of records. It should only be used when uniqueness or summarization is required.

Uploaded by

Satish Namballa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Typically it is used for collect records to append into internal table......

COLLECT Syntax Diagram


Basic form

COLLECT [wa INTO] itab.


Addition:
... SORTED BY f
In an ABAP Objects context, a more severe syntax check is
performed that in other ABAP areas. See Short forms of line
operations not allowed.

Effect

COLLECT allows you to create unique or summarized datasets.


The system first tries to find a table entry corresponding to
the table key (see Key definition for internal tables). The
key values are taken either from the header line of the
internal table itab, or from the explicitly-specified work
area wa. itab must have a flat structure, that is, it may not
contain other internal tables. All components that are not
part of the key must be have numeric types (see ABAP numeric
types).
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:
- STANDARD 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, or
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.
- SORTED TABLE:
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.
- HASHED TABLE:
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 independent of 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.

Notes

1. 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.
2. If you use COLLECT with a work area, the work area must be
compatible with the line type of the internal table.
3. 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 dataset
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 table.
Example

Summarized sales figures by company:


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
Tiger

40
20

Addition

... SORTED BY f

Effect

COLLECT ... SORTED BY f is obsolete, and should no longer be


used. It only applies to standard tables, and has the same
function as APPEND ... SORTED BY f, which you should use
instead. (See also obsolete statements.)

Note

Performance:
1. Avoid unnecessary assignments to the header line when using
internal tables with a header line. Whenever possible, use
statements that have an explicit work area.
For example, "APPEND wa TO itab." is approximately twice as
fast as "itab = wa. APPEND itab.". The same applies to
COLLECT and INSERT.
2. The runtime of a COLLECT increases with the width of the
table key and the number of numeric fields whose contents
are summated.

Note

Runtime errors:
- COLLECT_OVERFLOW: Overflow in an integer field during
addition
- COLLECT_OVERFLOW_TYPE_P: Overflow in a type P field during
addition.
- TABLE_COLLECT_CHAR_IN_FUNCTION: COLLECT on a non-numeric
field.

You might also like