SAP Architect Internal Tables Interview Questions

Internal Tables comes up in SAP Architect interviews because it is one of the few areas where an interviewer can tell, in two questions, whether you have worked with the process or only read about it.

Master standard, sorted and hashed internal tables with real ABAP performance, debugging and interview scenarios.

This page carries 10 reviewed SAP Architect internal tables interview questions, each with a complete written answer and no sign-in required. The set breaks down into 3 foundational, 6 mid-level and 1 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

The fastest way to use this page is to read the question, answer it yourself, and only then read the answer. The gap between your version and the written one is your actual revision list for internal tables.

10 Internal Tables questions with answers

easyInternal Tables

1. Explain the difference between READ TABLE ... TRANSPORTING NO FIELDS, table expressions itab[ ] and the modern LINE_EXISTS( ) / LINE_INDEX( ).

TRANSPORTING NO FIELDS with sy-subrc = 0 is a low-level existence check that avoids copying the row. Table expressions itab[ key = ... ] read the row directly and raise CX_SY_ITAB_LINE_NOT_FOUND if missing; LINE_EXISTS( ) and LINE_INDEX( ) are safe existence and index helpers without exceptions. Prefer the modern predicate functions when you only need to test presence, and table expressions inside TRY when you also need the row.

easyInternal Tables

2. What is the difference between STANDARD, SORTED, and HASHED internal tables?

STANDARD: linear index, allows duplicates, best for sequential processing and APPEND. Access by index is O(1), by key is O(n). SORTED: maintained in key order, unique or non-unique, binary search on key giving O(log n). HASHED: unique key only, hash access O(1), no index access. Choose HASHED for large unique-key lookups, SORTED for range reads in order, STANDARD for building/appending sets.

easyInternal Tables

3. How would you delete duplicates from a large standard internal table efficiently while keeping the first occurrence of each key?

SORT itab BY key1 key2 ..., then DELETE ADJACENT DUPLICATES FROM itab COMPARING key1 key2. This is O(n log n) instead of the O(n^2) nested-loop approach. If the sort order matters afterwards, capture the original index in an added column before sorting, or copy the required keys into a hashed lookup table and rebuild the result.

mediumInternal Tables

4. You need to aggregate 2 million line items by cost centre in memory. Which internal table type and technique would you use?

Use a HASHED table keyed on cost centre with an amount field, and COLLECT into it (or use REDUCE with GROUP BY in 7.5x). Hashed COLLECT is near O(1) per row and avoids the O(n) scan of a standard table COLLECT. If memory becomes a concern, aggregate in chunks read from the DB and free the driver table with FREE / CLEAR when the aggregate is ready.

mediumInternal Tables

5. What is the risk of using ASSIGNING FIELD-SYMBOL( <fs> ) after a DELETE inside the same LOOP?

After DELETE the field symbol may point to invalid or reused memory and the next read can return stale data or dump. Safe patterns: exit the loop, restart with the mutated table; use an index-based DO / WHILE where you control the index after DELETE; or collect indices to delete and apply them in reverse order after the LOOP.

mediumInternal Tables

6. Explain deep vs flat internal tables and the memory implications when passing them between methods.

Deep tables contain fields such as strings, references, or nested tables that are stored separately with pointers. Copying a deep table copies the row structure and each deep component; wide deep tables can consume large amounts of memory quickly. Prefer pass by reference (CHANGING or IMPORTING with REFERENCE) or field symbols for large deep tables. Flat tables (only elementary components) benefit from ABAP copy-on-write, so pass-by-value is cheap until modification.

mediumInternal Tables

7. A LOOP AT itab REFERENCE INTO dref is modifying the table and you are getting unexpected results. What is happening and how do you fix it?

REFERENCE INTO exposes a pointer to the row; modifying fields is fine, but INSERT / DELETE on the same table during the loop invalidates the reference and can corrupt iteration. Fix by (1) collecting rows to change into a helper table and applying changes after the loop, or (2) using LOOP AT ... ASSIGNING FIELD-SYMBOL(<row>) with an index-based loop that you control, or (3) rebuilding the target table via VALUE #( FOR row IN itab WHERE ... ).

mediumInternal Tables

8. You have a HASHED table keyed on document number and need frequent range access on the posting date. What table type and keys would you use and why?

Use a SORTED table with a non-unique key on posting_date, or keep the HASHED table and add a SECONDARY SORTED key on posting_date. Hashed access remains O(1) for single-key reads, and the sorted secondary key enables efficient READ ... WITH KEY posting_date BETWEEN ... queries and LOOP ranges. Rebuilding a secondary key has a one-time cost so measure with runtime analysis before applying it.

mediumInternal Tables

9. You need to compare two versions of an internal table (before / after) and produce a delta of inserts, updates, and deletes. How do you approach it?

Sort both tables by the business key. Use a two-pointer walk or a LOOP with READ TABLE ... BINARY SEARCH on the counterpart to classify rows: present only in before = deleted, only in after = inserted, in both with different non-key fields = updated. For large sets, load both into hashed tables keyed on the business key and iterate the union of keys; this gives O(n) with clear semantics.

hardInternal Tables

10. For a large VBAP-like table cached in memory across dialog steps, what design would you use to keep memory predictable in a busy production system?

Do not hold large itabs in static class attributes; the memory stays in the work process. Use SAP shared memory objects (CL_ABAP_MEMORY_AREA) or shared buffer with size limits and expiry, so multiple work processes can share the read-only data safely. Alternatively read from HANA on demand using key access — with HANA a well-designed CDS view is often faster than caching. Always measure with SM04 / ST02.

Next practice step

Practice with Interview AI Take a mock test

SAP Architect Internal Tables Interview Questions

10 Internal Tables questions with answers

1. Explain the difference between READ TABLE ... TRANSPORTING NO FIELDS, table expressions itab[ ] and the modern LINE_EXISTS( ) / LINE_INDEX( ).

2. What is the difference between STANDARD, SORTED, and HASHED internal tables?

3. How would you delete duplicates from a large standard internal table efficiently while keeping the first occurrence of each key?

4. You need to aggregate 2 million line items by cost centre in memory. Which internal table type and technique would you use?

5. What is the risk of using ASSIGNING FIELD-SYMBOL( <fs> ) after a DELETE inside the same LOOP?

6. Explain deep vs flat internal tables and the memory implications when passing them between methods.

7. A LOOP AT itab REFERENCE INTO dref is modifying the table and you are getting unexpected results. What is happening and how do you fix it?

8. You have a HASHED table keyed on document number and need frequent range access on the posting date. What table type and keys would you use and why?

9. You need to compare two versions of an internal table (before / after) and produce a delta of inserts, updates, and deletes. How do you approach it?

10. For a large VBAP-like table cached in memory across dialog steps, what design would you use to keep memory predictable in a busy production system?

Related lesson

Related topics

Next practice step