ITAB_ILLEGAL_INDEX — ITAB_ILLEGAL_INDEX dump causes and fixes

ITAB_ILLEGAL_INDEX is raised by the kernel when a statement tries to read, insert, delete, or modify an internal table row by its ordinal position and that position is not valid for the table in question. There are two distinct triggers hiding behind one dump name. The first is a numeric one: the index passed is zero, negative, or otherwise outside what the runtime accepts as a row number before it even checks table length. The second is structural: the statement uses INDEX-based addressing (READ TABLE ... INDEX, LOOP AT ... FROM/TO, table expression itab[ n ], INSERT/DELETE/MODIFY ... INDEX) against a HASHED table, which is stored and retrieved by hash key, not by row position, so any index-based operation against it is illegal by definition regardless of the value supplied.

If the cause is index-based access on a HASHED table, the access statement has to be rewritten to use key-based READ TABLE WITH KEY, or LOOP AT ... WHERE, or the table declaration has to change to SORTED or STANDARD if ordered/positional access is genuinely required elsewhere in the same routine. Either path is a code change requiring a transport and, in a customer-owned program, a proper change request; in an SAP-delivered program it should be raised through standard support channels rather than modified directly. If the cause is a stale sy-tabix after the table shape changed, the fix is to stop caching row positions across mutating statements and instead re-read by key, or to collect keys to act on and process them in a second pass after the loop. If the cause is an empty table with a hardcoded index, add a length check (lines( itab ) > 0) or switch to a table expression wrapped in TRY/CATCH for CX_SY_ITAB_LINE_NOT_FOUND before assuming row one exists. If two tables have drifted out of alignment, the real fix is to stop relying on positional correspondence and join or match by key instead.

The common first move is to wrap the offending statement in a blanket TRY...CATCH against cx_root or the generic itab exception class and swallow it, or to bolt on an IF sy-tabix <= lines( itab ) check written after the fact without understanding why the index went wrong. Both suppress the dump but leave the defect in place: on a HASHED table the check never fires because the problem is the table kind, not the value, so processing silently skips rows or writes to the wrong record, and the real defect resurfaces later as a data discrepancy that is much harder to trace than a dump with a clean stack.

Treat table kind as part of the interface contract: any routine that receives a table parameter generically (ANY TABLE, generic type, or a type determined only at runtime) should check the table kind explicitly or restrict itself to key-based access only. Extended program check and ABAP Test Cockpit checks for table access consistency should be run on any code touching internal tables declared HASHED, since this is the single largest source of this dump. Avoid caching sy-tabix across statements that can change table content, and prefer FOR loops over manual index counters where the table might be re-sorted or filtered mid-routine.

This is an ABAP development defect, not a Basis issue; Basis involvement is limited to confirming it is not a kernel or memory-related side effect. The handover to the developer should include the program, include and line from ST22, the table name and its declared kind, the index value at the time of failure, and the business document or transaction that triggered the run so the data condition can be reproduced.

table-invalid-index is the closely related dump raised in similar index-based table access scenarios and should be checked alongside this one when triaging a batch of similar short dumps. itab-duplicate-key points to a related but distinct defect class on HASHED and SORTED tables, arising from key uniqueness rather than positional access. uncaught-exception and raise-exception are worth checking when the failing statement is a table expression (itab[ n ]), since an unhandled CX_SY_ITAB_LINE_NOT_FOUND from that syntax can appear as a generic uncaught exception dump rather than as ITAB_ILLEGAL_INDEX directly, depending on the exact statement used.