TABLE_INVALID_INDEX — TABLE_INVALID_INDEX Short Dump

The dump is raised when a statement performing indexed access on an internal table — READ TABLE ... INDEX, LOOP AT ... FROM/TO, MODIFY ... INDEX, DELETE ... INDEX, or a table expression such as itab[ n ] — is handed an index that is not a legitimate table position. This is a stricter condition than simply being out of range: the index is zero, negative, or the result of an arithmetic operation that never produced a valid whole number in the first place. ABAP catches this before it even attempts to walk the table's internal line structure, because the index value itself fails the basic sanity check. It is functionally distinct from the sibling dump ITAB_ILLEGAL_INDEX, where the index is a plausible positive number but exceeds the current row count of the table. Both belong to the same family of table-access exceptions and are catchable in a TRY/ENDTRY block if the calling code is written that way, but by default they terminate the program.

If the cause is arithmetic underflow, add an explicit IF index > 0 (or CHECK) guard before the indexed statement and decide what the code should do on the boundary case — skip, default to the first row, or raise a handled exception. If the cause is sy-tabix leakage across nested loops, save the outer loop's sy-tabix into a dedicated local variable immediately on entering the outer LOOP AT, and use that variable rather than sy-tabix once an inner loop is present. If the cause is unvalidated external input, validate the index against lines( itab ) and its sign before any table access, and reject or normalize invalid values at the interface boundary rather than downstream. If the cause is a 0-based/1-based mismatch across an interface, fix the conversion at the point where the parameter enters the ABAP layer, not inside every consuming routine. All of the above are custom-code fixes requiring a normal transport and change request. If the terminating statement sits inside SAP standard code, the fix path changes: raise an incident with SAP support rather than modifying the standard object directly, and treat the immediate workaround as a temporary manual data correction, not a permanent code change.

The reflex fix is wrapping the offending statement in TRY/CATCH for CX_SY_ITAB_LINE_NOT_FOUND, or adding an IF sy-subrc <> 0 check after switching to a form that returns a return code, and calling it done once the dump stops. This suppresses the symptom but leaves the row that should have been processed silently skipped. The underlying arithmetic or loop-nesting bug keeps generating a bad index on every run; it just no longer terminates the program, it quietly drops data instead, which is harder to detect and harder to explain later when totals do not reconcile.

Enforce a code standard that any manually computed index used in READ TABLE, MODIFY, DELETE, or a table expression is bounds-checked immediately before use, and that sy-tabix is never referenced inside a routine containing more than one LOOP AT without being captured into a named variable first. Prefer LOOP AT ... ASSIGNING <fs> and functional expressions such as line_exists() and line_index() over manual index arithmetic wherever the logic allows it — they eliminate the class of bug entirely. Code inspector checks can flag raw sy-tabix use inside nested loops as a warning during transport release.

Custom code: ABAP development owns it, fixed through a normal change request with the bounds check and a regression test covering the boundary row (first, last, and empty table). Standard SAP code: functional team raises the incident, Basis is only involved if the dump is tied to a mass job or background processing chain that needs rescheduling. The handover note should include the program, include, and line, the index variable's value at termination, and whether the table was empty, single-row, or multi-row when it failed.

ITAB_ILLEGAL_INDEX is the closely related dump for the same family of statements when the index is a valid positive number but exceeds the table's row count — the two are commonly mistaken for each other during a quick ST22 read. Where the calling code does not wrap the access in a TRY/ENDTRY block, either dump can surface upstream as an UNCAUGHT_EXCEPTION or, if the developer added a bare RAISE without a proper handler, as RAISE_EXCEPTION further up the call stack.