Explain Internal Tables & Table Operations in SAP

2 / 65

ABAPbeginner

Internal Tables & Table Operations

Working with ABAP's core in-memory data structure for processing sets of records efficiently.

An internal table is a table held in memory inside your program. Almost every ABAP report, BAPI or service ends up looping over one.

A standard table is a stack of index cards in the order you dropped them in; a sorted table is a card catalog always in alphabetical order; a hashed table is a phone directory app that jumps straight to the entry by name with no scanning at all.

Key Concepts

Picking the wrong type is the most common cause of an ABAP program that works in testing and times out in production.

Three types, three ways of finding a row.

    STANDARD   rows in insertion order. Finding by key reads
               row by row until it matches.          slow lookups, fast appends
    SORTED     kept in key order. Finding by key uses
               a binary search.                      log n lookups
    HASHED     a hash of the key gives the position
               directly. No index access at all.     constant-time lookups

Why this matters, with numbers. Reading one row from a standard table of 10,000 entries compares up to 10,000 rows. A sorted table needs about 14 comparisons, a hashed table one.

That difference is invisible until it is inside a loop.

The single most common ABAP performance bug. A read nested inside a loop:

    LOOP AT lt_orders INTO ls_order.            " 10,000 rows
      READ TABLE lt_customers INTO ls_customer  " 10,000 rows, standard
           WITH KEY id = ls_order-customer_id.
    ENDLOOP.

The loop runs 10,000 times and each read scans up to 10,000 rows: up to 100 million comparisons. With test data of 50 orders it is instant. With real data the job runs for hours.

Declaring lt_customers as a hashed table changes the inner cost from 10,000 to 1 — the same code, roughly ten thousand times faster.

lt_customers

    DATA lt_customers TYPE HASHED TABLE OF ty_customer
                      WITH UNIQUE KEY id.

Reading rows: three forms.

    READ TABLE lt WITH KEY id = 4.              " linear unless the table is sorted/hashed
    READ TABLE lt WITH TABLE KEY id = 4.        " uses the declared key; needs a sorted/hashed table
    ls = lt[ id = 4 ].                          " table expression, modern and concise

The table expression raises CX_SY_ITAB_LINE_NOT_FOUND when there is no match, so it is wrapped in a TRY or guarded with line_exists( lt[ id = 4 ] ). The older forms set sy-subrc instead.

CX_SY_ITAB_LINE_NOT_FOUNDTRYline_exists( lt[ id = 4 ] )sy-subrc

Modern constructs that replace loops.

    lt_open  = FILTER #( lt_orders WHERE status = 'O' ).
    lv_total = REDUCE i( INIT s = 0 FOR w IN lt_orders NEXT s = s + w-amount ).
    lt_ids   = VALUE #( FOR w IN lt_orders ( w-id ) ).

Shorter, and harder to accidentally make quadratic.

Loop with a condition, not a check inside. LOOP AT lt WHERE status = 'O' lets the runtime use the table's key where it can. A plain loop with an IF inside always visits every row.

LOOP AT lt WHERE status = 'O'IF

Control breaks, for sorted output. AT NEW field, AT END OF field and SUM produce subtotals while looping. They depend on the table being sorted by those fields — on unsorted data they silently produce wrong groupings.

AT NEW fieldAT END OF fieldSUM

Choosing. Looked up by key and read often: hashed, if the key is unique. Needs both key access and sorted output: sorted. Only ever looped through end to end, or appended to: standard.

What the interviewer is probing.1. "When would you use a hashed table?" Probing: whether you choose by access pattern. Stalls: "They are faster." Moves up: unique key lookups only — access is constant time regardless of size, but there is no index access and no sorting.

2. "Why avoid READ TABLE with a non-key field on a standard table?" Probing: the cost. Stalls: "It is fine." Moves up: it is a linear scan, so inside a loop it becomes quadratic — sort and use a binary search, or use a sorted or hashed table.

3. "What does a field symbol save you?" Probing: the performance reason. Stalls: "Nothing." Moves up: it avoids copying the row into a work area, which matters in large loops and lets you modify the row in place.

4. "What is the problem with nested loops over internal tables?" Probing: the scaling trap. Stalls: "Readability." Moves up: the cost multiplies, so ten thousand by ten thousand rows is a hundred million iterations — use a sorted parallel cursor instead.