GETWA_NOT_ASSIGNED — Field Symbol Not Assigned Runtime Error

The dump means the program executed an operation on a field symbol before the field symbol was bound to a memory area. Field symbols in ABAP are references without their own storage; they must be pointed at a concrete field, structure, or internal table row via ASSIGN before use. If the ASSIGN never ran, ran on the wrong branch, or ran but failed silently because nobody checked sy-subrc, the field symbol is left dangling. Any subsequent statement that reads or writes through it - a MOVE, a WRITE, a comparison, passing it as a parameter - triggers the runtime error rather than returning a blank value. This is generally not something a TRY/CATCH block around the offending statement will rescue cleanly; the safe point to intervene is before the dereference, not after.

If the cause is an unchecked ASSIGN, add an explicit IF sy-subrc <> 0 or IF <fs> IS ASSIGNED branch immediately after the ASSIGN and decide what the program should actually do when the target does not exist - skip the record, raise a proper application error, or log it - rather than letting execution fall through. If the cause is a loop that may not execute, guard the post-loop logic with a check on sy-subrc from the loop or an explicit line count check on the table before relying on the field symbol. If the cause is a dynamic component name that is wrong, correct the string construction logic or the customizing table feeding it; this is a code change and needs a transport. If the cause is a structure change from an upgrade or support package, compare the structure in the affected system against the version the code was written against, and adjust the field name referenced - this is a code fix requiring a change request, since it will recur on every future landscape refresh otherwise. If the cause is genuinely a data condition that was never supposed to happen, fix the data first, then still add the defensive check so the same dump cannot recur with different data.

The reflex fix is wrapping the failing line in IF <fs> IS ASSIGNED and simply skipping the block when it is not, without asking why the assignment failed. The dump stops, which looks like success, but the record that would have been processed is now silently dropped or left with a blank value that flows downstream - into a posting, an interface, or a report total - with no error raised anywhere. The second common reflex, wrapping the statement in a broad TRY/CATCH against a generic exception class, has the same effect: it suppresses the visible symptom while leaving the actual data or logic gap in place, and the next person to investigate a wrong result has no dump to start from.

Every ASSIGN, ASSIGN COMPONENT, and dynamic ASSIGN statement should be followed by an explicit sy-subrc or IS ASSIGNED check before the field symbol is used, as a non-negotiable code review standard for anything touching dynamic field access. Code that loops with ASSIGNING should never assume the loop executed at least once; test the table's line count or the loop's own sy-subrc first. Static ABAP unit tests should include an empty-table case for every LOOP ... ASSIGNING pattern. Where structures are referenced dynamically by name, prefer RTTI-based checks against the structure description before the ASSIGN rather than relying on the ASSIGN itself to fail safely.

ABAP development owns this dump in nearly all cases, since it originates in custom code, a BAdI implementation, or an enhancement, even when triggered by a standard transaction. Basis is only involved if the cause traces to a support package or upgrade that changed a standard structure. The handover note should state the program, include, and line from ST22, the field symbol name, the ASSIGN statement that failed, and whether the failure is data-driven or structural.

Closely related dumps involve the same class of dynamic-access failure: OBJECTS-OBJREF-NOT-ASSIGNED covers the equivalent problem for object references rather than field symbols, ITAB-ILLEGAL-INDEX and TABLE-INVALID-INDEX cover invalid row access on internal tables, and ASSIGN-LENGTH-0 or DATA-LENGTH-0 cover related dynamic offset and length failures. All are usually raised inside custom code, BAdI implementations, or user exits reached from a standard transaction, and all point back to insufficiently defensive dynamic ABAP.