The COLLECT Statement in ABAP: Syntax, Examples & Table Types

Category
ABAP-Statements
Published
Author
Johannes

The COLLECT statement is a special command in ABAP used for condensing or aggregating data in an internal table. The special feature of COLLECT is:

  1. It checks whether a row already exists in the target table whose key matches the row to be added. The “key” for COLLECT always consists of all non-numeric fields of the table row (i.e., everything except types I, P, F, DECFLOAT16/34).
  2. If a row with identical non-numeric key is found: The values of all numeric fields of the row to be added are added to the values of the corresponding numeric fields of the already existing row.
  3. If no row with identical non-numeric key is found: The row to be added is inserted as a new entry in the table (similar to APPEND for standard tables or INSERT for hash tables).

COLLECT is therefore ideal for building sums or counts based on certain characteristics (e.g., total quantity per material and plant).

Syntax

COLLECT <wa> INTO <internal_table>
[ASSIGNING <field_symbol> | REFERENCE INTO <data_reference>].
  • COLLECT: The ABAP keyword.
  • <wa>: A work area (structure) that is compatible with the row type of <internal_table>.
    • The non-numeric fields in <wa> form the key for the search/aggregation.
    • The numeric fields in <wa> contain the values that may be added to an existing row.
  • INTO <internal_table>: The target internal table where aggregation or insertion occurs.
  • ASSIGNING <field_symbol> / REFERENCE INTO <data_reference> (Optional): After the operation, the field symbol or data reference points to the row in the table that was either newly inserted or whose numeric values were just updated. This is useful for direct access to the result.

Behavior by Table Type (Important!)

The suitability and efficiency of COLLECT strongly depends on the type of target table:

1. Standard Tables (STANDARD TABLE)

  • COLLECT is allowed.
  • The search for a row with matching non-numeric key is done through sequential reading of the table. This can become very slow for large tables!
  • If no matching key is found, the row from <wa> is appended at the end of the table (like APPEND).
  • sy-tabix is set to the index of the modified or newly appended row.

2. Hashed Tables (HASHED TABLE)

  • COLLECT is allowed and often the most efficient use case, BUT ONLY IF the unique key (UNIQUE KEY) of the hash table consists exactly of all non-numeric fields of the row structure and contains no numeric fields.
  • If this condition is met, COLLECT uses the hash algorithm for a very fast key search.
  • If no matching key is found, the row is inserted (like INSERT).
  • sy-tabix is undefined here (usually 0), as the index plays no role for hash tables.
  • Caution: If the defined key of the hash table does not match the implicit COLLECT key (all non-numeric fields), using COLLECT leads to a runtime error!

3. Sorted Tables (SORTED TABLE)

  • Using COLLECT with sorted tables is strongly discouraged and often leads to runtime errors!
  • COLLECT ignores the defined sort order of the table and only works with its own implicit key (all non-numeric fields). Inserting or aggregating can violate the sorting and lead to inconsistent states or direct aborts.
  • For aggregations in sorted tables: Use manual logic instead with READ TABLE <table> WITH KEY ... BINARY SEARCH, followed by MODIFY <table> ... (if found) or INSERT <wa> INTO TABLE <table> (if not found).

System Fields

  • sy-subrc: Is normally always set to 0 by COLLECT, regardless of whether a row was aggregated or newly inserted. It is therefore not a good indicator of what happened.
  • sy-tabix: Only meaningful for standard tables, where it contains the index of the processed/newly inserted row. For hash tables it is 0/undefined.

Examples

1. Aggregation in Standard Table (Quantity per Material)

TYPES: BEGIN OF ty_mat_quant,
material TYPE string, " Key (non-numeric)
quantity TYPE i, " Value (numeric)
END OF ty_mat_quant.
DATA: lt_summary TYPE STANDARD TABLE OF ty_mat_quant,
ls_data TYPE ty_mat_quant.
ls_data = VALUE #( material = 'M-01' quantity = 10 ).
COLLECT ls_data INTO lt_summary.
ls_data = VALUE #( material = 'M-02' quantity = 5 ).
COLLECT ls_data INTO lt_summary.
ls_data = VALUE #( material = 'M-01' quantity = 7 ). " Will be added to M-01
COLLECT ls_data INTO lt_summary.
cl_demo_output=>display( lt_summary ).
" Output:
" Material | Quantity
" ---------|---------
" M-01 | 17
" M-02 | 5

2. Efficient Aggregation in Hashed Table (Quantity per Material/Plant)

TYPES: BEGIN OF ty_stock,
matnr TYPE matnr, " Part of the key
werks TYPE werks_d, " Part of the key
menge TYPE i, " Value
END OF ty_stock.
" Key of the hash table MUST correspond to the non-numeric fields!
DATA lt_stock_agg TYPE HASHED TABLE OF ty_stock
WITH UNIQUE KEY matnr werks.
DATA ls_stock TYPE ty_stock.
ls_stock = VALUE #( matnr = 'MAT1' werks = '1000' menge = 100 ).
COLLECT ls_stock INTO lt_stock_agg.
ls_stock = VALUE #( matnr = 'MAT2' werks = '1000' menge = 50 ).
COLLECT ls_stock INTO lt_stock_agg.
ls_stock = VALUE #( matnr = 'MAT1' werks = '1000' menge = 25 ). " Will be added
COLLECT ls_stock INTO lt_stock_agg.
ls_stock = VALUE #( matnr = 'MAT1' werks = '2000' menge = 200 ). " New entry
COLLECT ls_stock INTO lt_stock_agg.
cl_demo_output=>display( lt_stock_agg ).
" Output (order in hash is not defined):
" Matnr | Werks | Menge
" ------|-------|------
" MAT1 | 1000 | 125
" MAT2 | 1000 | 50
" MAT1 | 2000 | 200

3. Using ASSIGNING

FIELD-SYMBOLS: <fs_stock_line> LIKE LINE OF lt_stock_agg.
ls_stock = VALUE #( matnr = 'MAT1' werks = '1000' menge = 5 ).
COLLECT ls_stock INTO lt_stock_agg ASSIGNING <fs_stock_line>.
IF <fs_stock_line> IS ASSIGNED.
WRITE: / 'Aggregated/New row:', <fs_stock_line>-matnr, <fs_stock_line>-werks, 'Quantity:', <fs_stock_line>-menge.
" Output e.g.: Aggregated/New row: MAT1 1000 Quantity: 130 (if 125 was in there before)
ENDIF.

Important Notes / Best Practice

  • COLLECT is the special tool for aggregating numeric values based on a non-numeric key in internal tables.
  • It modifies the target table directly.
  • For optimal performance, use COLLECT with hashed tables whose key is correctly defined (Unique Key = all non-numeric fields).
  • Do not use COLLECT with sorted tables – use READ TABLE/MODIFY/INSERT instead.
  • For standard tables, consider the potential performance implications with large data volumes.