Skip to content

ABAP Keyword Documentation →  ABAP Programming Guidelines →  Robust ABAP →  Dynamic Programming Techniques 

Accessing Data Objects Dynamically

Other versions: 7.31 | 7.40 | 7.54

Background

Field symbols and data references are used to access data objects whose name and attributes are not known until runtime.

  • Field symbols
    A field symbol is a symbolic name for a data object declared with FIELD-SYMBOLS, to which memory areas can be assigned using the ASSIGN statement or, if internal tables are processed, using the ASSIGNING addition. Field symbols are typed either generically or completely and can be used like a data object in all appropriate operand positions. For typing, the same rules apply as for formal parameters of procedures. When accessing field symbols, value semantics applies, which means that the assigned memory content is addressed directly. Field symbols are thus always handled like dereferenced pointers.
  • Data references
    A data reference is the content of a data reference variable that is declared using REF TO and points to any data objects or parts of data objects. Data references are needed to create anonymous data objects using CREATE DATA or NEW. They can also be generated for existing data objects, however, using the statement GET REFERENCE, the reference operator REF, or, if internal tables are processed, using the REFERENCE INTO addition. A data reference variable is either completely generic or completely typed. When accessing data reference variables, reference semantics applies, which means that the data reference itself is addressed. To access the referenced memory content, a data reference variable must be dereferenced explicitly using the dereferencing operator (->*).

Field symbols and data references are closely linked because only completely typed data reference variables can be dereferenced in any operand position. Completely generic data reference variables (REF TO data) can be dereferenced in the ASSIGN statement only.

Data reference variables can be declared in the same context as all other data objects, especially also as attributes of classes. Field symbols, in contrast, can only be declared within procedures (methods) or in the global declaration part. However, the latter is no longer allowed.

Rule

Use field symbols and data references in appropriate ways

Use field symbols and data references for the purpose that best matches their semantics:

  • Field symbols for value access (value semantics)
  • Data references for working with the references (reference semantics)

Details

Both field symbols and data references can be understood as pointers to memory areas. The main difference is in the different access semantics.

  • Due to their value semantics, field symbols should always be used if the focus is on the access to referenced data. Field symbols provide specific functions for this purpose, which are not available for data references:
  • Dynamic access to attributes of classes and objects
    ASSIGN (class_name)=>(attr_name) ...
    ASSIGN oref->(attr_name) ...
  • Dynamic access to structure components
    ASSIGN ... COMPONENT ...
  • Explicit casting
    ASSIGN ... CASTING ...
  • Dereferencing of generic data reference variables
    ASSIGN dref->* ...
  • Due to their reference semantics, data references are to be used if the focus is on the explicit handling of references to data objects. Data references are vital for creating anonymous data objects or complex dynamic data structures, such as trees or chained lists in the internal session or in the shared objects memory. Furthermore, data references are the preferred element for implementing explicit sharing between any data objects, and for passing pointers to data objects to procedures.


Note

Actually, data reference variables can be better used in programs that are based on ABAP Objects because they have the same semantics as object reference variables and therefore represent a more modern programming concept. Field symbols, on the other hand, provide more functions than data references and can thus not always be replaced by them. Consequently, the usage of field symbols for dynamic accesses to data objects is still recommended, although the sole use of data references would be preferred for consistency and simplicity reasons.

Bad Example

The following source code shows a loop for an internal table in which the system is supposed to directly access the current row. If a generic data reference variable is used for this purpose, a field symbol is also needed for its dereferencing.

METHOD some_method.
  "IMPORTING i_itab TYPE INDEX TABLE
  DATA dref TYPE REF TO data.
  FIELD-SYMBOLS <fs> TYPE data.
  ...
  LOOP AT i_itab REFERENCE INTO dref.
    ASSIGN dref->* TO <fs>.
    <fs> = ...
  ENDLOOP.
  ...
ENDMETHOD.

Good Example

The following source code simplifies the above example by using a field symbol, which is required to access table rows anyway, directly and without using a data reference. The direct use of the field symbol thus also complies with the KISS principle.

METHOD some_method.
  "IMPORTING i_itab TYPE INDEX TABLE
  FIELD-SYMBOLS <fs> TYPE data.
  ...
  LOOP AT i_itab ASSIGNING <fs>.
    <fs> = ...
  ENDLOOP.
...
ENDMETHOD.