Articles

ABAP Internal Table Interview Questions: Keys, Table Types, and Lookup Costs

Practice ABAP internal table interview questions with standard, sorted, and hashed tables, explicit keys, duplicate handling, and lookup cost trade-offs.

The strongest ABAP internal table interview answer starts with the access contract: which keys are unique, which queries are frequent, whether order matters, and how often rows change. Choosing HASHED TABLE because “hashing is fast” can be wrong when the application needs ranges, duplicate keys, or index access.

Official facts below come from SAP's ABAP documentation and SAP-maintained examples. Candidate reports: none are used to assert employer question frequency. Original exercises: the order-line declarations and workload comparisons are practice cases. Code is intended for a compatible modern ABAP environment; it has been reviewed against documented syntax, not executed on a SAP runtime for this article. Rehearse this distinction with Implement a custom list with iterator and map.

How do standard, sorted, and hashed tables differ?

Official categories: a standard table has a nonunique primary key and can have an empty key. A sorted table maintains primary-key order and can use a unique or nonunique primary key. A hashed table uses a unique primary hash key and has no primary table index. Secondary keys can provide additional access paths. SAP's table-key overview.

That gives you a starting contract, not a complete performance verdict. Standard-table key searches generally require linear search when no optimized path applies. Sorted-key access can exploit its ordering when the search fits the key. Full hash-key access is designed for efficient exact lookup; a partial free-key condition does not automatically obtain that access path. SAP's internal table examples.

The useful interview distinction is “which operation uses which key?” An attractive declaration does not accelerate every expression written against it. Include population, reads, updates, memory, and output order in your choice.

Exercise: choose a table for order lines

Our fictional workload stores order lines identified by (order_id, line_no). Each pair is unique, but an order has multiple lines. Most requests need either one exact line or all lines of an order. Imports may contain duplicate pairs that must be rejected or resolved explicitly.

TYPES: BEGIN OF ty_line,
         order_id TYPE i,
         line_no  TYPE i,
         amount   TYPE p LENGTH 8 DECIMALS 2,
       END OF ty_line.

DATA lt_sequence TYPE STANDARD TABLE OF ty_line
                 WITH EMPTY KEY.
DATA lt_ordered TYPE SORTED TABLE OF ty_line
                WITH UNIQUE KEY order_id line_no.
DATA lt_exact TYPE HASHED TABLE OF ty_line
              WITH UNIQUE KEY order_id line_no.

The standard table preserves the primary sequence used by its index, but an empty primary key does not provide fast business-key lookup. The sorted table's key groups each order's lines together and supports exact-key reasoning. The hashed table represents exact unique pairs but does not provide primary-index positions or sorted order by that pair.

If both exact lookup and per-order iteration dominate, the sorted table is a plausible first choice. A standard table with carefully chosen secondary keys is another candidate when preserving the input sequence matters. A hashed table can be appropriate if exact lookup dominates and range-style access is unnecessary.

State the decision conditionally. You have not benchmarked the application's actual row width, distribution, mutation pattern, or ABAP environment. The exercise establishes semantic fit; measurement establishes the practical winner.

Why does a partial key change the answer?

For (order_id, line_no), an exact lookup supplies both components. A query for all lines of one order supplies a leading part of the sorted key. A query for every row with line_no = 2 supplies a nonleading component.

These are different access patterns. Do not assign all three the same “logarithmic lookup” label just because the table is sorted. If the leading condition identifies a range, locating the range and processing its k matches are separate costs. Returning many rows still takes work proportional to the output.

A full hash-key lookup can identify one pair. Supplying only order_id cannot identify a unique hash-key value, because each order has several lines. A hashed declaration therefore does not turn the per-order query into a constant-time range retrieval.

Requested operation	Key contract to explain
Find order 7, line 2	Exact composite lookup; decide missing-row behavior.
Visit every line of order 7	Leading sorted-key range, plus work for each matching line.
Find every line numbered 2	Nonleading search; consider a separate key only if the workload justifies it.
Return the third input row	Requires the intended sequence/index, not the business-key order.
Reject repeated order-line pairs	Enforce uniqueness and define what the caller sees on conflict.

This operation matrix is the first topic-specific asset. Use it to challenge an interviewer's follow-up: “What changes if ninety percent of requests are per-order scans rather than exact lookups?” The workload change may justify a different declaration.

Do secondary keys get used automatically?

Official guidance: secondary keys add memory and maintenance costs and should be explicitly named when used. They can improve access without replacing the primary table category, but declaration alone is not a guarantee that a given statement selects the intended key. SAP's key-component guidance.

For a sequence-preserving table that also needs exact and per-order access, consider this declaration:

DATA lt_lines TYPE STANDARD TABLE OF ty_line
  WITH EMPTY KEY
  WITH UNIQUE HASHED KEY by_pair COMPONENTS order_id line_no
  WITH NON-UNIQUE SORTED KEY by_order COMPONENTS order_id.

READ TABLE lt_lines
  WITH TABLE KEY by_pair COMPONENTS order_id = 7 line_no = 2
  INTO DATA(ls_found).

IF sy-subrc = 0.
  "Process the found row.
ENDIF.

LOOP AT lt_lines INTO DATA(ls_order_line)
  USING KEY by_order WHERE order_id = 7.
  "Process this order's lines.
ENDLOOP.

There are now three distinct views of the same table: primary sequence, exact pair lookup, and sorted order grouping. Explain which one each statement requests. If the workload does not need all three, the additional indexes may be unnecessary overhead.

Secondary-key maintenance can be deferred in some documented cases. Include first access after population or mutation in a benchmark; measuring only a warmed read path can hide the cost you paid elsewhere. Do not generalize one lazy-update behavior to every unique and nonunique key.

How should you handle duplicate keys?

A duplicate business key is a data-contract decision before it is an ABAP syntax question. Does the import reject it, replace the existing value, combine amounts, or retain both rows? “Use a hash table” does not answer that.

For the exercise, suppose duplicate pairs are rejected. With a unique primary key, a single-row INSERT ... INTO TABLE can signal a duplicate through sy-subrc; inspect the documented behavior of the actual operation. Constructors, bulk operations, and unique secondary-key violations have different failure surfaces, so do not claim every duplicate becomes the same return code. SAP's examples and duplicate-key discussion.

INSERT VALUE ty_line(
  order_id = 7 line_no = 2 amount = '25.00'
) INTO TABLE lt_exact.

IF sy-subrc <> 0.
  "Handle the duplicate according to the import contract.
ENDIF.

Test an identical replay and a conflicting replay separately. If the first pair contains amount 25 and the second contains 40, silent “keep the first” may hide a correction. If retries are allowed, distinguish idempotent replay from conflicting data before choosing replacement semantics.

Do not pick a nonunique sorted key simply to avoid handling duplicates when the domain requires uniqueness. Conversely, declaring uniqueness for a naturally one-to-many relationship can reject valid data.

Are table expressions safer or faster than READ TABLE?

A table expression is concise syntax for accessing a row. It does not create a new key or change the access path's fundamental contract. Official behavior: an unhandled missing row in a normal table expression raises CX_SY_ITAB_LINE_NOT_FOUND; permitted OPTIONAL or DEFAULT forms and other access patterns let you make missing-row behavior explicit. SAP's table-expression documentation.

DATA(ls_optional) = VALUE ty_line(
  lt_exact[ order_id = 7 line_no = 2 ] OPTIONAL
).

This can return an initial structure when absent. Ask whether an initial structure could also be a valid row in your domain. If so, the caller needs a separate existence distinction; treating all initial values as “not found” is ambiguous.

Likewise, checking line_exists and then reading performs two logical accesses and may be unnecessary when a single read with explicit handling suffices. Explain clarity and cost rather than declaring one syntax universally superior.

For an interview trace, compare three cases: present pair, absent pair, and a present row whose nonkey fields are initial. Your answer should identify the result and failure handling for each, not merely recite the expression.

What can go wrong with SORT and BINARY SEARCH?

BINARY SEARCH on a standard table depends on an appropriate ascending sort order for the search components. Sorting by an unrelated field or a different component order invalidates the assumption. A later mutation can invalidate a manually maintained sort invariant.

Official sorting behavior: standard and hashed tables can be explicitly sorted for processing, while sorted tables maintain their primary-key order. Sorting is not stable by default; use STABLE when preservation of equal-key relative order is part of the contract. SAP's sorting guidance.

The interview trap is recommending a one-time sort without considering subsequent writes. If the code sorts once, appends unsorted rows, and continues binary searching, the claimed performance solution also introduced a correctness risk.

A sorted table or explicit sorted secondary key can express an invariant the runtime maintains. That does not mean it is always the best choice: measure maintenance costs when the workload mutates frequently. The question is who owns the ordering invariant and what it costs to maintain.

Can you change key fields in place?

Official restriction: primary-key fields of sorted and hashed table rows cannot be modified like ordinary nonkey fields. Their values determine the primary organization. SAP's key rules.

If an order-line identity must change, design an explicit remove-and-reinsert operation with conflict handling. Consider what happens if the new key already exists; do not delete the old row and then lose it on insertion failure. The exact safe implementation depends on the surrounding application contract.

Updating an amount is a different operation from changing order_id. Secondary keys can add further restrictions and maintenance work. A field symbol or reference does not bypass table-key requirements.

What would you measure before choosing the final type?

Benchmark the whole workload: fill, first keyed access, steady reads, misses, mutations, and output traversal. Include the same rows, key distribution, and row width. Record which key every measured statement actually uses.

A tiny table can make linear search competitive because setup and maintenance dominate. A large read-heavy table may favor a maintained access path. A table with several secondary keys can use substantially more memory than its raw row payload suggests.

Explain expected complexity as a model, then verify observed time and memory in the actual ABAP runtime. This article does not provide timing numbers because no SAP runtime benchmark was performed. The useful interview answer is a reproducible measurement proposal with a semantic justification.