Internal-table pitfalls
What you'll learn
BINARY SEARCH on an unsorted table silently returns garbage with no dump — and a field symbol already edits the row, so MODIFY ... INDEX is redundant.
- BINARY SEARCH on an unsorted table = undefined result, NO dump — only use it on ascending-sorted data.
- LOOP ... INTO copies the row; LOOP ... ASSIGNING <fs> binds it in place (faster, mutable).
- MODIFY ... INDEX inside a field-symbol loop is redundant — assigning to <fs> already mutated the row.
The sharpest internal-table trap is silent and never dumps: READ TABLE ... BINARY SEARCH on a table that is *not* sorted ascending by the search key gives an *undefined* result — usually 'not found' on a row that is present. There is no runtime error, so the bug surfaces as missing data far from its cause. BINARY SEARCH is a promise you make to the runtime about the table's order; if you cannot keep it, use a SORTED or HASHED table whose order the kernel maintains for you.
The access-mode choice is about copies. LOOP AT itab INTO ls copies each row into the work area; LOOP AT itab ASSIGNING FIELD-SYMBOL(<fs>) binds the field symbol to the row in place with no copy, which is faster and lets you mutate the row directly. Because <fs> *is* the row, a MODIFY itab INDEX sy-tabix FROM <fs> inside that loop is pure redundancy — the assignment to <fs> already changed the table.
The remaining pitfalls are about cost and stability. DELETE itab WHERE is an O(n) scan even on a SORTED table when the WHERE does not align with the sort key. INSERT INTO TABLE on a HASHED table is O(1) on average but the bucket array grows by reallocation — declare INITIAL SIZE when the row count is roughly known. And SORT is *unstable* by default: rows equal on the sort key may be reordered. If a prior order must be preserved among equal keys, you must write SORT itab STABLE BY f.
Key points
- BINARY SEARCH on an unsorted table = undefined result, NO dump — only use it on ascending-sorted data.
- LOOP ... INTO copies the row; LOOP ... ASSIGNING <fs> binds it in place (faster, mutable).
- MODIFY ... INDEX inside a field-symbol loop is redundant — assigning to <fs> already mutated the row.
- SORT is unstable unless you add STABLE; HASHED inserts benefit from INITIAL SIZE; DELETE ... WHERE is O(n).
Examples
lt_data was never sorted by id; the binary search may report sy-subrc 4 for a row that exists — silently, no dump.
ABAPread table lt_data into data(ls)
with key id = lv_id binary search.Sort first (or use a SORTED table), and mutate via the field symbol — the row is updated in place with no MODIFY.
ABAPsort lt_data stable by id.
loop at lt_data assigning field-symbol(<row>).
<row>-status = 'DONE'.
endloop. " <- the assignment above already updated the tableSource notes: clean-core-curriculum §10.2
Ask Claude
Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.