ABAP APPEND Statement Explained: Adding Rows to Internal Tables

Important Distinction from `INSERT`

APPEND: Always adds at the end. Primarily intended for standard tables.
INSERT: Can insert at a specific index position (for standard tables with INDEX) or inserts according to key sorted or hashed (for Sorted/Hashed tables with INTO TABLE).

Syntax

There are three main variants:

Append a single row from a work area (<wa>):

APPEND <wa> TO <internal_table> [ASSIGNING <field_symbol> | REFERENCE INTO <data_reference>].
" Addition [SORTED BY <component>] is obsolete and should not be used.

Append a single initial row:

APPEND INITIAL LINE TO <internal_table> [ASSIGNING <field_symbol> | REFERENCE INTO <data_reference>].

Append multiple rows from another table (<source_table>):

APPEND LINES OF <source_table> [FROM <index1>] [TO <index2>] TO <internal_table>
                             [KEEPING DUPLICATES | DELETING DUPLICATES]. " Relevant for Sorted/Hashed

Components

<wa>: A work area (structure) that must be compatible with the row type of <internal_table>. Its content is copied into the new row.
INITIAL LINE: Adds a row where all components have their type-specific initial value (e.g., 0 for numbers, spaces for type C, empty string for type STRING).
LINES OF <source_table>: Copies rows from <source_table> and appends them to the end of <internal_table>. Optionally, FROM <index1> and TO <index2> can limit the range of rows to copy from the source table.
TO <internal_table>: The target table to append to.
ASSIGNING <field_symbol> / REFERENCE INTO <data_reference>: (Only for APPEND <wa> / INITIAL LINE) Very useful! Sets a field symbol or data reference pointing directly to the just appended row. This saves a subsequent READ TABLE when you want to directly edit the new row.
KEEPING DUPLICATES / DELETING DUPLICATES: (Only for APPEND LINES OF) These additions affect behavior when attempting to append rows to a sorted or hashed table (which is generally problematic, see below). They relate to key uniqueness. For standard tables, they have no effect on content duplicates.

How It Works / Behavior by Table Type

The behavior and admissibility of APPEND strongly depends on the internal table type:

1. Standard Tables (`STANDARD TABLE`)

APPEND adds the row(s) always at the physical end of the table. The order of existing rows is not changed.
This is the typical and recommended use case for APPEND.
The system field sy-tabix contains the index of the (last) appended row after the operation. sy-subrc is typically 0.

2. Sorted Tables (`SORTED TABLE`)

APPEND <wa> or APPEND INITIAL LINE is fundamentally forbidden here, as appending at the end would violate the guaranteed sort order of the table. An attempt leads to a runtime error (dump).
Exception: APPEND LINES OF may work under certain circumstances if the rows to append happen not to violate the sort order or if duplicates are handled according to the key (with KEEPING/DELETING DUPLICATES). However, it is not the correct way to add data to sorted tables.
Correct statement for sorted tables: INSERT <wa> INTO TABLE <table>.

3. Hashed Tables (`HASHED TABLE`)

APPEND <wa> or APPEND INITIAL LINE is strictly forbidden here. The position of a row in a hashed table is determined by the hash value of the unique key, not by insertion order. An APPEND attempt leads to a runtime error.
Exception: APPEND LINES OF can theoretically be used but leads to a runtime error for any unique key violation (unless the source already contained duplicates and DELETING DUPLICATES was used, which primarily cleans the source).
Correct statement for hashed tables: INSERT <wa> INTO TABLE <table>.

System Fields

sy-subrc: For APPEND on standard tables, usually 0. For APPEND LINES OF on Sorted/Hashed, sy-subrc may be set to 4 if duplicates were handled according to the additions, but key violations usually result in runtime errors here.
sy-tabix: After APPEND on a standard table, sy-tabix contains the row index of the (last) newly appended row.

Examples (Focus on Standard Tables)

TYPES: BEGIN OF ty_component,
         comp_id   TYPE i,
         comp_text TYPE string,
       END OF ty_component.

DATA: gt_components TYPE STANDARD TABLE OF ty_component WITH EMPTY KEY,
      gs_component  TYPE ty_component.

FIELD-SYMBOLS: <fs_component> LIKE LINE OF gt_components.

" 1. Append work area
gs_component = VALUE #( comp_id = 10 comp_text = 'Component A' ).
APPEND gs_component TO gt_components.

gs_component = VALUE #( comp_id = 20 comp_text = 'Component B' ).
APPEND gs_component TO gt_components.

WRITE: / 'After APPEND <wa>: ', lines( gt_components ), 'rows.'.

" 2. Append initial row and edit directly with ASSIGNING
APPEND INITIAL LINE TO gt_components ASSIGNING <fs_component>.
IF <fs_component> IS ASSIGNED.
  <fs_component>-comp_id = 30.
  <fs_component>-comp_text = 'Component C (initial)'.
  WRITE: / 'Last row (ASSIGNING):', <fs_component>-comp_text.
ELSE.
  WRITE: / 'Error with APPEND ASSIGNING'.
ENDIF.

" 3. Append rows from another table
DATA gt_source LIKE gt_components.
APPEND VALUE #( comp_id = 40 comp_text = 'Component D' ) TO gt_source.
APPEND VALUE #( comp_id = 50 comp_text = 'Component E' ) TO gt_source.

APPEND LINES OF gt_source TO gt_components.

WRITE: / 'After APPEND LINES OF: ', lines( gt_components ), 'rows.'.

" Output entire table
cl_demo_output=>display( gt_components ).

Important Notes / Best Practice

Use APPEND to quickly and easily add rows to the end of standard tables.
For sorted and hashed tables, use INSERT ... INTO TABLE ... to ensure table consistency and avoid runtime errors.
The addition ASSIGNING <field_symbol> (or REFERENCE INTO) with APPEND <wa> / INITIAL LINE is very performant when you want to edit the newly added row immediately afterward.
To iterate through all rows of a table, use LOOP AT.
To sort a table after filling it, use SORT.