SAP ABAP Internal Tables Complete Guide: Standard, Sorted, Hashed & Modern Syntax

SAP ABAP internal tables are used in almost every real project, interview, report, interface, enhancement, and RAP or S/4HANA development task. The syntax is easy; choosing the correct table category and key is where performance and maintainability are won or lost.

This complete guide covers standard, sorted, and hashed tables; modern table expressions; line_exists; FILTER; FOR; REDUCE; secondary keys; safe reads; common mistakes; and a practical decision checklist.

Quick answer: Use a STANDARD table for sequential processing or small temporary collections, a SORTED table for ordered/range access, and a HASHED table for frequent exact reads with a unique complete key.

1. What is an internal table in ABAP?

An internal table is an in-memory collection of rows with a defined line type and one or more table keys. Unlike a database table, its lifetime is normally limited to the current ABAP session or program context. It is used to collect, transform, group, validate, and display application data.

Every declaration has three decisions:

• Line type: Which fields does each row contain?
• Table category: STANDARD, SORTED, or HASHED?
• Key: Which components identify or order the rows?

2. Standard vs sorted vs hashed table

Type	Best for	Key rule	Typical access
STANDARD	Sequential loops, index access, small/append-heavy data	Unique or non-unique; explicit EMPTY KEY is often clearest	Linear key search unless a suitable secondary key or binary search is used
SORTED	Ordered output, leading-key and range access	Unique or non-unique; rows remain in key order	Binary access when the search uses the appropriate leading key components
HASHED	Frequent exact lookup by a full unique key	Primary key must be unique	Hash access when the complete key is supplied

STANDARD table example

DATA lt_messages TYPE STANDARD TABLE OF string WITH EMPTY KEY.

APPEND `Created` TO lt_messages.
APPEND `Validated` TO lt_messages.

LOOP AT lt_messages INTO DATA(message).
  out->write( message ).
ENDLOOP.

A standard table is a sensible default when the program mainly appends rows and processes them sequentially. A free-key read is normally linear, so repeated key reads over large data should trigger a design review.

SORTED table example

DATA lt_sorted TYPE SORTED TABLE OF ty_flight
               WITH NON-UNIQUE KEY carrid connid.

INSERT VALUE #( carrid = 'LH' connid = '0400' price = 450 )
  INTO TABLE lt_sorted.

LOOP AT lt_sorted INTO DATA(flight)
  WHERE carrid = 'LH'.
  out->write( flight ).
ENDLOOP.

The runtime maintains the primary sort order. Do not apply SORT to a statically known sorted table. Use it when ordered iteration and leading-key ranges are important.

HASHED table example

DATA lt_hashed TYPE HASHED TABLE OF ty_flight
               WITH UNIQUE KEY carrid connid.

INSERT VALUE #( carrid = 'LH' connid = '0400' price = 450 )
  INTO TABLE lt_hashed.

READ TABLE lt_hashed INTO DATA(flight)
  WITH TABLE KEY carrid = 'LH' connid = '0400'.

A hashed table is ideal for dictionary-style lookup using the complete unique key. It has no primary index, so index-dependent logic and sy-tabix-based assumptions do not belong in this design.

3. Safe reads: READ TABLE, table expressions and line_exists

A table expression is concise:

DATA(flight) = lt_hashed[ carrid = 'LH' connid = '0400' ].

If no matching line exists, a direct table expression can raise CX_SY_ITAB_LINE_NOT_FOUND. Choose the handling method that reflects the business case:

• Use line_exists( itab[ ... ] ) when you only need a yes/no check.
• Use VALUE #( itab[ ... ] OPTIONAL ) when an initial result is acceptable.
• Use READ TABLE ... ASSIGNING when you need sy-subrc, want to modify the found row, or prefer explicit classic flow.
• Catch CX_SY_ITAB_LINE_NOT_FOUND when absence is exceptional and should be handled as such.

Performance note: Avoid checking with line_exists and immediately reading the same row in a hot loop. That can perform two lookups. Read once when you need the row.

4. Modern transformations with FILTER, FOR and REDUCE

FILTER

DATA(lt_lh) = FILTER #( lt_sorted WHERE carrid = 'LH' ).

FILTER returns a new internal table containing matching rows. The available optimization depends on compatible table keys, so define the source table and access pattern deliberately.

FOR expression

DATA(lt_ids) = VALUE string_table(
  FOR row IN lt_flights
  ( |{ row-carrid }-{ row-connid }| ) ).

FOR is useful for mapping one table into another without a separate helper variable. Keep the expression short enough that another developer can understand it during code review.

REDUCE

DATA(total_price) = REDUCE s_price(
  INIT sum = CONV s_price( 0 )
  FOR row IN lt_flights
  NEXT sum = sum + row-price ).

REDUCE calculates one result from repeated iterations—for example a total, count, maximum, flag, or concatenated value. Use explicit result types for currency, quantity, and packed-number calculations.

5. Secondary keys: faster access without duplicating the table

A secondary table key provides an additional sorted or hashed access path. This is useful when the same collection needs sequential processing plus frequent reads by another key.

TYPES ty_flight_tab TYPE STANDARD TABLE OF ty_flight
  WITH EMPTY KEY
  WITH UNIQUE HASHED KEY by_connection
    COMPONENTS carrid connid
  WITH NON-UNIQUE SORTED KEY by_price
    COMPONENTS price.

Secondary keys are not free. They require memory and must be maintained when rows are inserted, deleted, or key fields are changed. Add them for measured or clearly dominant access patterns—not simply because they exist.

6. BINARY SEARCH: when and how to use it

SORT lt_standard BY carrid connid.

READ TABLE lt_standard INTO DATA(flight)
  WITH KEY carrid = 'LH'
           connid = '0400'
  BINARY SEARCH.

The standard table must already be sorted in ascending order by the components used for binary search, in the correct priority. If the order is wrong, the program may not find a row that exists. For repeated access, a sorted table or a suitable secondary key is often clearer and safer.

7. Common mistakes and better alternatives

1. Using a standard table for thousands of repeated key reads: choose a sorted/hashed table or an appropriate secondary key.
2. Declaring an implicit default key: use a meaningful explicit key or WITH EMPTY KEY.
3. Applying BINARY SEARCH without matching SORT order: keep the sort and read key aligned, or redesign the table type.
4. Using a hashed table for range processing: a sorted key is normally a better fit.
5. Catching a missing table-expression row nowhere: use OPTIONAL, line_exists, READ TABLE, or an explicit exception strategy.
6. Copying every row into a work area: use ASSIGNING or references when modification/copy cost matters.
7. Adding many secondary keys blindly: account for memory and update overhead and measure the real workload.

8. Interview-ready decision guide

• Need original insertion order or index access? STANDARD.
• Need sorted output and range/leading-key reads? SORTED.
• Need the fastest exact lookup by a unique complete key? HASHED.
• Need several access patterns over one table? Consider secondary sorted/hashed keys.
• Need only one pass over small data? Prefer clarity; a standard table may be enough.

9. Practical checklist before transport

• Is the line type minimal and clearly named?
• Does the primary key match the dominant access pattern?
• Is uniqueness a real business rule?
• Are missing rows handled intentionally?
• Are repeated reads performed through an optimized key?
• Are expressions readable and testable?
• Have realistic data volumes been measured with SAT, ST12, or another suitable runtime tool?
• Are release-specific language features compatible with the target ABAP system?

10. Frequently asked questions

Which internal table is fastest in ABAP?

There is no universally fastest category. Hashed tables suit exact full-key reads, sorted tables suit ordered and range access, and standard tables suit sequential/index-oriented processing. The access pattern, row count, write frequency, memory, and key selectivity decide the best option.

Is table expression faster than READ TABLE?

The table category and selected key usually matter more than the surface syntax. Choose table expressions for concise value access and READ TABLE when its explicit result handling or assignment behavior is clearer.

When should I use WITH EMPTY KEY?

Use it for a standard table when primary-key semantics are intentionally unnecessary. It documents that choice and avoids relying on the implicit standard key.

Can a sorted table contain duplicates?

Yes. A sorted table can use a unique or non-unique primary key. A hashed table primary key is always unique.

Should I always replace loops with FOR or REDUCE?

No. Expressions are excellent when they make a transformation obvious. A conventional loop can be more maintainable when debugging, branching, exception handling, or side effects are involved.

Official SAP references

• Creating Internal Tables — SAP Help Portal
• Distinguishing Table Keys — SAP Help Portal
• READ TABLE, Free Key — SAP Keyword Documentation
• FOR Iteration Expressions — SAP Keyword Documentation
• Internal Table Built-in Functions — SAP Keyword Documentation

Compatibility note: Some modern syntax depends on the ABAP release and language version. Validate examples in your target system and adapt demo types such as flight data elements to your project’s released artifacts.