ABAP New Syntax Lecture 1: Inline DATA and FIELD-SYMBOL Declarations

Inline declarations are one of the most useful ABAP new-syntax features. They let you declare a variable exactly where a compatible writing position needs it. This removes distant helper declarations, keeps the type close to the operation and often makes code easier to review.

Learning goal: After this lecture you will understand DATA(...), FIELD-SYMBOL(...), type inference, scope, practical table and SQL patterns, and when an explicit declaration remains the better choice.

1. Classic declaration vs inline declaration

In classic ABAP, a variable is declared first and filled later. With an inline declaration, the compiler derives a complete static type from the declaration position.

" Classic
DATA lv_text TYPE string.
lv_text = 'Hello ABAP'.

" Inline
DATA(lv_text_new) = 'Hello ABAP'.

The declaration happens at compile time. The variable becomes visible from that position in the current context. Inline syntax is not a dynamically typed shortcut—the variable still has a static type inferred by the compiler.

2. Where can DATA(...) be used?

DATA(var) can appear at a compatible declaration position where the compiler can derive the full type. Common examples include assignment results, method-return values, loops, reads, SQL targets and constructor expressions.

Assignment and functional method result

DATA(lv_name) = 'SAP 4 ALL'.
DATA(lv_upper) = to_upper( lv_name ).
DATA(lv_length) = strlen( lv_name ).

Use meaningful names even when the variable is local. Shorter syntax should not produce cryptic code.

LOOP AT ... INTO DATA(...)

LOOP AT lt_flights INTO DATA(ls_flight).
  out->write( ls_flight-carrid ).
ENDLOOP.

The compiler derives the row type from lt_flights. The work area is visible from the declaration position according to normal ABAP visibility rules; do not assume its lifetime is limited to one loop iteration.

READ TABLE with an inline target

READ TABLE lt_flights INTO DATA(ls_first) INDEX 1.
IF sy-subrc = 0.
  out->write( ls_first ).
ENDIF.

Always handle the unsuccessful-read case intentionally. An inline target makes the declaration concise but does not remove the need to check sy-subrc.

3. Inline field symbols

A field symbol is an alias for an assigned memory area. Inline FIELD-SYMBOL(<...>) is especially convenient for internal-table processing.

LOOP AT lt_flights ASSIGNING FIELD-SYMBOL(<flight>).
  <flight>-price = <flight>-price * '1.05'.
ENDLOOP.

Unlike INTO, ASSIGNING does not create a separate copied work area. Updating the assigned field symbol updates the corresponding table line. This is powerful, so use it only when direct modification is intended.

4. Inline declarations with modern Open SQL

SELECT FROM scarr
  FIELDS carrid, carrname, currcode
  WHERE carrid = @lv_carrid
  INTO TABLE @DATA(lt_carriers).

The result table type follows the selected columns. The @ sign identifies host variables in modern Open SQL. Demo objects such as SCARR may not be available or released in every environment, particularly ABAP Cloud, so replace them with suitable project APIs.

5. DATA(...) vs FINAL(...)

Where supported, FINAL(...) expresses that a variable should receive its value once and should not be changed afterwards. Use it when immutability communicates intent. If your target release does not support it, use DATA(...) and avoid unnecessary reassignment by convention.

6. When explicit declarations are better

• The type is part of an important business rule and should be visible immediately.
• A conversion, length or decimal definition must be controlled precisely.
• The inferred type would be surprising to another developer.
• A variable is used across a large section and a central declaration improves navigation.
• Your supported ABAP release or language version does not allow the inline form.

7. Common mistakes

1. Assuming every operand position allows DATA(...): it must be a documented declaration position with a fully derivable type.
2. Ignoring numeric inference: literals and expressions can infer a type that is unsuitable for currency or quantity calculations. Use an explicit type or CONV when precision matters.
3. Using generic field symbols carelessly: verify assignment and understand whether changes affect the original object.
4. Forgetting failed reads: inline READ TABLE still needs an intentional sy-subrc strategy.
5. Compressing too much: a short expression is not automatically more maintainable than clear multi-step code.

8. Practice exercises

1. Convert three classic helper declarations in an existing report to inline declarations.
2. Write one loop using INTO DATA(...) and another using ASSIGNING FIELD-SYMBOL(...). Explain the behavioural difference.
3. Select two columns from a released data source into an inline internal table.
4. Find a case where an explicit numeric type is safer than inference.
5. Refactor a method while keeping every inline variable close to its first meaningful use.

9. Interview questions

Is DATA(...) dynamically typed?

No. The compiler derives a static type from the declaration position.

Does INTO DATA(...) modify the original internal-table row?

No. INTO works with a target work area. Use ASSIGNING when you intentionally need direct access to the table line.

Can inline declarations replace every DATA statement?

No. They are allowed only at suitable declaration positions, and explicit declarations are often clearer when type semantics matter.

Lecture 1 checklist

• I understand how ABAP infers an inline variable’s type.
• I can use inline targets in assignments, loops, reads and SQL.
• I know the difference between INTO and ASSIGNING.
• I still check failed reads and release compatibility.
• I choose explicit types when precision or business meaning requires them.

← ABAP New Syntax Course Index

Official SAP references

• DATA — Inline Declaration, ABAP Keyword Documentation
• Field Symbols — SAP Help Portal
• ABAP 7.40 Language Enhancements — SAP Help Portal

Compatibility note: Available syntax depends on the ABAP release and language version. Test every example in your target development system.