DATA_LENGTH_0 — DATA_LENGTH_0 Runtime Error Diagnosis

DATA_LENGTH_0 is a runtime error raised by the ABAP kernel when a statement needs to operate on a data object of positive byte length but the object handed to it resolves to length zero at runtime. This is a structural problem, not a content problem: an empty field is still a valid field with a real length, but the object involved here genuinely has no length at all, usually because it was built dynamically and ended up with zero components, or because a reference variable was cast against a type descriptor that never carried a length. The kernel cannot compute an offset, move bytes, or reserve memory for something with no length, so it terminates rather than silently producing garbage. Because the failing statement is frequently deep inside a standard function module or a generic ABAP List Viewer or RTTI routine that was handed a caller-supplied structure, the short dump often points at kernel-owned or SAP-owned code even though the real defect sits in the calling program.

If the cause is a dynamically built structure with zero components, trace back to the field catalog or component table construction and add a validation step that raises a controlled exception or default type when the input list is empty, rather than letting an empty descriptor flow into MOVE or ASSIGN; this is a code fix requiring a transport. If the cause is an empty field catalog feeding a generic display or export routine, correct the logic that builds the catalog (missing join, wrong filter, wrong customizing lookup) so it always returns at least the mandatory fields; also a code change. If the cause is a DDIC structure or append inconsistency after transport, re-activate the structure and its dependents in the correct sequence and re-transport; this is a Basis or ABAP development task depending on who owns the transport chain, and does need a change request. If the cause is a generic interface parameter in a BAdI or user-exit receiving an unbound table type, fix the implementation to bind a concrete line type before calling the standard logic, or correct the interface definition if it is customer-owned. None of these are runtime-only fixes; all require a code or DDIC change and a retest of the failing transaction.

The common reflex is to wrap the failing statement in a TRY/CATCH block, or to add an IF field IS NOT INITIAL guard before the MOVE or ASSIGN, and call the dump fixed once the short dump stops appearing. This does not fix anything: the underlying type still has zero length, the guard just skips the operation silently, and the program either does nothing where it should have processed data, or fails later downstream with a different, harder-to-diagnose symptom such as missing rows in an output list or a blank field in a BAPI response.

Any code that builds a type descriptor or field catalog dynamically should assert a non-zero component count immediately after construction, before the descriptor is used in ASSIGN, CREATE DATA, or MOVE. Custom BAdI and user-exit implementations that accept generically typed table or structure parameters should validate the bound line type at the top of the implementation rather than assuming the caller always supplies a concrete type. Structure and append changes should go through a standard activation and transport sequence check before being released to test systems, so inconsistent partial activations are caught before they reach production.

This is an ABAP development problem in nearly every case, since the fix is always in code or DDIC metadata, not runtime configuration. Basis gets involved only when the cause is a transport or activation inconsistency across systems. The handover note should include the exact statement and program from ST22, the name and active length of the structure or type involved, and whether the type is built statically or dynamically at that point in the call.

Closely related to ASSIGN_LENGTH_0, which fires under similar dynamic-typing conditions but at an explicit field-symbol ASSIGN with an offset or length specification. Also related to DATA_OFFSET_LENGTH_TOO_LARGE, which is the sibling error when the length is non-zero but exceeds the object, and to GETWA_NOT_ASSIGNED, which shows up when the field symbol itself was never assigned at all. MOVE_CAST_ERROR often appears in the same code paths, since both stem from dynamic type handling gone wrong during a cast or generic move.