Skip to content

SETWA_NOT_ALLOWED

A write operation was attempted on a field-symbol pointing to a read-only area.

The field-symbol was successfully assigned, but the memory area it points to is write-protected. Attempting to change the value through the field-symbol triggers this dump.

Symptom

ST22 shows one of:

Runtime Errors         SETWA_NOT_ALLOWED
Short text             The current field symbol must not be changed.

or on newer kernels when the read-only area is a literal:

Runtime Errors         MOVE_TO_LIT_NOTALLOWED_NODATA
Short text             Cannot change a literal or a read-only section.

The root cause is identical — a write through a field-symbol to a protected memory area. The exact dump name depends on the type of protected area and the kernel release.

The dump line is the assignment statement that tries to write through the field-symbol.

Cause

Common read-only areas that trigger this dump:

  • Literals and constants — ASSIGN 'HELLO' TO <fs>. followed by <fs> = 'WORLD'.
  • Text symbols — text symbols (TEXT-001) are stored in read-only memory.
  • CASTING beyond the actual field length — assigning with CASTING TYPE to a longer type than the source, then writing to the extended area.
  • Read-only database fields — some DB interface fields passed as constants.

Dump name varies by kernel and source type

Assigning a string literal ('VALUE') or SY-* system field to a field-symbol and writing to it typically raises MOVE_TO_LIT_NOTALLOWED_NODATA on modern kernels. SETWA_NOT_ALLOWED is more commonly seen when writing to read-only areas from external memory, CASTING overflows, or protected text symbols. Both dumps mean the same thing: the field-symbol points to memory ABAP will not let you overwrite.

Reproduce

REPORT z_setwa_not_allowed.

START-OF-SELECTION.

  FIELD-SYMBOLS: <fs> TYPE any.

  ASSIGN 'READ_ONLY_LITERAL' TO <fs>.
  <fs> = 'NEW_VALUE'.   " <-- SETWA_NOT_ALLOWED or MOVE_TO_LIT_NOTALLOWED_NODATA

Which dump name you see depends on your kernel

On modern SAP kernels this reproduces as MOVE_TO_LIT_NOTALLOWED_NODATA. On older kernels it appears as SETWA_NOT_ALLOWED. The fix is identical in both cases — see below.

Fix

DATA lv_value TYPE string VALUE 'HELLO'.
FIELD-SYMBOLS: <fs> TYPE string.

ASSIGN lv_value TO <fs>.
<fs> = 'WORLD'.   " works — lv_value is writable
WRITE <fs>.

DATA lv_date TYPE d.
FIELD-SYMBOLS: <fs> TYPE d.

lv_date = sy-datum.          " copy SY field into a writable variable
ASSIGN lv_date TO <fs>.
<fs> = '20250101'.           " works — lv_date is writable
WRITE <fs>.

" If you need to read through a field-symbol and produce a modified copy,
" work with a separate variable instead of writing back through the symbol:
DATA lv_value TYPE string VALUE 'original'.
FIELD-SYMBOLS: <fs> TYPE string.

ASSIGN lv_value TO <fs>.

" Modify a copy, not the field-symbol itself
DATA lv_copy TYPE string.
lv_copy = <fs>.              " read the value
lv_copy = to_upper( lv_copy ).
WRITE lv_copy.

Prevention

  • Never ASSIGN a literal, constant, or text symbol to a field-symbol if you intend to write through it.
  • Never write through a field-symbol pointing to SY-* fields — copy them to a DATA variable first.
  • As a general rule: if you need to modify the value, assign to a DATA variable and use a field-symbol pointing to that variable.
  • Code reviews should flag any ASSIGN <literal> pattern where the field-symbol is subsequently written — it is always either a read-only usage or a latent SETWA_NOT_ALLOWED bug.

See also

Comments