LLM Pitfall

STRING vs CHAR Confusion in ABAP

LLMs default to TYPE string for almost every text variable. In ABAP, this is often wrong — and interfacing with DDIC structures will silently behave differently than you expect.

The Problem

Python has one string type. JavaScript has one string type. LLMs are trained heavily on both. When they write ABAP, they carry this "one string type" assumption into the code and reach for TYPE string everywhere.

ABAP has two fundamentally different text types: STRING (dynamic length, heap-allocated) and CHAR(n) / C(n) (fixed length, value semantics). They look similar in a WRITE statement but behave very differently in real SAP scenarios.

Why It Matters

Trailing spaces

CHAR(10) is always exactly 10 characters, padded with spaces. STRING contains only what you assign. Comparisons like IF lv_char = 'ABC' behave differently depending on type.

DDIC compatibility

DDIC domains and table fields are almost always typed as CHAR. Assigning a STRING to a structure field that expects CHAR triggers an implicit conversion — or a runtime error in strict contexts.

Database field mapping

SAP database tables store text as fixed-length CHAR. If your work area field is TYPE string instead of matching the DDIC type, you'll hit type mismatch issues at the database layer.

Performance

STRING variables are heap-allocated references. In tight loops over large internal tables, using STRING where CHAR would suffice wastes memory and increases GC pressure.

How to Spot It

Look for these patterns in LLM-generated code that are likely to cause problems:

DATA lv_xxx TYPE string — when the variable will be moved into a DDIC structure or used in a SELECT WHERE clause
DATA ls_header TYPE string — using STRING for a variable that is clearly meant to be a short code or key (e.g., material number, company code)
Structure fields typed TYPE string in a locally defined structure meant to mirror a database table row

The AI Validator in ABAP Dojo flags these patterns automatically using the llm-string-char-confusion rule.

The Fix

Use TYPE string when you genuinely need a dynamic-length text buffer — free-form text, concatenated messages, long descriptions. Use TYPE charn (or a DDIC reference like TYPE matnr) when you're working with codes, keys, or fields that map to database columns.

⚠ Pitfall — LLM-generated code:

REPORT ztest_pitfall1.
* LLM Pitfall: Using STRING where CHAR is expected
DATA lv_name TYPE string VALUE 'ABAP Dojo'.
DATA lv_code TYPE string VALUE '001'.
* In real SAP, lv_code might need to be TYPE char3
* to match a DDIC domain.
WRITE: 'Name:', lv_name.
WRITE: / 'Code:', lv_code.

✓ Correct — idiomatic ABAP:

REPORT ztest_correct1.
* Use CHAR(n) for fixed-length fields (codes, keys, DDIC-mapped fields)
* Use STRING only for variable-length text content
DATA lv_name TYPE string VALUE 'ABAP Dojo'.   " OK: display text, no DDIC constraint
DATA lv_code TYPE char3  VALUE '001'.         " Correct: fixed 3-char code
DATA lv_matnr TYPE matnr.                     " Best: use DDIC domain directly
lv_matnr = '000000000000100042'.
WRITE: 'Name:', lv_name.
WRITE: / 'Code:', lv_code.
WRITE: / 'Matnr:', lv_matnr.

Rule of thumb: If the value goes into a structure, a SELECT statement, or anything that touches the DDIC, match the DDIC type. Reserve TYPE string for pure in-memory text manipulation — user messages, output strings, dynamic content you build at runtime.

Quick Reference

Scenario	Use
Company code, plant, material number	TYPE bukrs / werks / matnr
Short fixed-length code with no DDIC type	TYPE char<n>
Long description, free-form text	TYPE string
Concatenated messages, output strings	TYPE string
Structure field mirroring a DB table column	TYPE <ddic_type>

Try the pitfall code in ABAP Dojo's AI Validator to see the rule fire in real time.

Validate this code in ABAP Dojo →