ASSIGN_TYPE_CONFLICT

A value was assigned to a typed field-symbol whose type is incompatible.

The ASSIGN statement succeeded in locating the memory area, but the type of the source is incompatible with the type declared on the field-symbol (FIELD-SYMBOLS: <fs> TYPE sometype).

Symptom

ST22 shows:

Runtime Errors         ASSIGN_TYPE_CONFLICT
Exception              CX_SY_ASSIGN_CAST_ILLEGAL_CAST
Short text             Type conflict when assigning to a field symbol.

The dump line is the ASSIGN statement, not the subsequent access.

This dump is not catchable with TRY/CATCH

Although ST22 lists CX_SY_ASSIGN_CAST_ILLEGAL_CAST as the exception class, ASSIGN_TYPE_CONFLICT fires as a kernel-level dump and bypasses the OO exception mechanism on most SAP systems. Wrapping the ASSIGN in a TRY block will NOT prevent the dump. The correct fix is to declare the field-symbol as TYPE any, or check IS ASSIGNED after the assignment.

Cause

A typed field-symbol enforces compatibility at assignment time:

• FIELD-SYMBOLS: <fs> TYPE i — only accepts integer-compatible areas.
• FIELD-SYMBOLS: <fs> TYPE string — only accepts string areas.
• FIELD-SYMBOLS: <fs> LIKE ls_row-amount — only accepts areas with the same type as amount.

Common triggers:

• Iterating a heterogeneous structure and assigning components of the wrong type to a typed field-symbol.
• Using ASSIGN COMPONENT n OF STRUCTURE with a typed field-symbol where different components have different types.
• A CASTING addition that specifies a type incompatible with the actual memory layout.

Reproduce

Static ASSIGN between incompatible known types is caught by the compiler — the dump occurs when the type conflict can only be detected at runtime. The most common trigger is ASSIGN COMPONENT:

REPORT z_assign_type_conflict.

START-OF-SELECTION.

  TYPES: BEGIN OF ty_row,
           name   TYPE string,
           amount TYPE p DECIMALS 2,
         END OF ty_row.

  DATA ls_row TYPE ty_row.
  FIELD-SYMBOLS: <num> TYPE i.

  " Component 1 (name) is TYPE string — assigning to TYPE i dumps at runtime
  ASSIGN COMPONENT 1 OF STRUCTURE ls_row TO <num>.
  WRITE <num>.   " never reached — dump happens on the ASSIGN line above

Dynamic variable name variant:

REPORT z_assign_type_conflict2.

START-OF-SELECTION.

  DATA: lv_num  TYPE i VALUE 42,
        lv_name TYPE string VALUE 'LV_NUM'.

  FIELD-SYMBOLS: <fs> TYPE string.

  " Dynamic ASSIGN resolves at runtime — i is not compatible with string → dump
  ASSIGN (lv_name) TO <fs>.

Fix

Use TYPE ANY (no type enforcement)Match the field-symbol type to the sourceIS ASSIGNED guard (for ASSIGN COMPONENT)

DATA lv_num TYPE i VALUE 42.
FIELD-SYMBOLS: <fs> TYPE any.

ASSIGN lv_num TO <fs>.   " works — TYPE ANY accepts everything
WRITE <fs>.

DATA lv_num TYPE i VALUE 42.
FIELD-SYMBOLS: <fs> TYPE i.

ASSIGN lv_num TO <fs>.   " works
WRITE <fs>.

TRY/CATCH does not work for this dump

ASSIGN_TYPE_CONFLICT fires as a kernel-level dump on most SAP systems — it does not go through the OO exception mechanism. Even though CX_SY_ASSIGN_CAST_ILLEGAL_CAST appears in ST22, wrapping the ASSIGN in a TRY block does NOT prevent the dump. Use TYPE any on the field-symbol or check IS ASSIGNED instead.

REPORT z_assign_type_fix_isassigned.

START-OF-SELECTION.

  TYPES: BEGIN OF ty_row,
           name   TYPE string,
           amount TYPE p DECIMALS 2,
         END OF ty_row.

  DATA: ls_row       TYPE ty_row,
        lv_fieldname TYPE string VALUE 'NAME'.

  " TYPE any — no type enforcement, no dump risk
  FIELD-SYMBOLS: <component> TYPE any.

  ASSIGN COMPONENT lv_fieldname OF STRUCTURE ls_row TO <component>.

  " Check IS ASSIGNED before use — handles both missing field and type mismatch
  IF <component> IS ASSIGNED.
    WRITE: / 'Field value:', <component>.
  ELSE.
    WRITE: / 'Field not found or type incompatible:', lv_fieldname.
  ENDIF.

Prevention

• Declare field-symbols as TYPE any when the target type is not known at development time — this eliminates the type check entirely.
• When iterating structure components dynamically with ASSIGN COMPONENT, always use TYPE any or TYPE data on the field-symbol, never a concrete type.
• After every ASSIGN COMPONENT, check IS ASSIGNED before accessing the field-symbol.
• Do not rely on TRY/CATCH cx_sy_assign_cast_illegal_cast — this dump bypasses the OO exception mechanism on most kernels and cannot be caught.

See also

• GETWA_NOT_ASSIGNED — accessing an unassigned field-symbol
• Transaction ST22 — ABAP runtime error analysis

Comments