Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing Internal Data →  Assignments →  = - Assignment Operator 

= - Assign Data Objects

Other versions: 7.31 | 7.40 | 7.54

Syntax


destination = dobj.

Effect

In the simplest assignment case, a data object dobj is on the right side of the assignment operator =. This data object can be specified as described under Reader Positions. The content of the data object is assigned to the left side, destination. If necessary, type-specific conversions are made in accordance with the conversion rules. The variant shown here applies to all assignments between operands that are not reference variables. Special rules apply to reference variables.

The following can be specified for destination:

  • Any data object that can be specified in a writer position. The data type of the data object must be either compatible with the data type of dobj or it must be possible to convert the content of dobj into the data type of destination in accordance with one of the conversion rules.
  • An inline declaration DATA(var). If the data type of dobj is complete, it is used for the declaration. If dobj is a generically typed field symbol or a formal parameter of this kind, the following data types are used:
  • string for csequence and clike
  • xstring for xsequence
  • decfloat34 for numeric and decfloat
  • p with the length 8 and no decimal places if p is generic
  • The standard key for a standard table type with generic primary table key
Other generic data types cannot be made concrete for the inline declaration in a useful way and produce a syntax error. An exception to this are table types that are explicitly generic with respect to their secondary table key, since these types are not relevant for the declared data object.


Notes

  • A special assignment operator, ?=, which performs a down cast, is available for assignments of reference variables.
  • If dobj and/or destination are field symbols, then, as in all ABAP commands, the system works with the content of the data objects to which the field symbols point. The actual pointer content of a field symbol can only be changed using the statement ASSIGN or the addition ASSIGNING when processing internal tables (value semantics).
  • Inline declarations are not possible for every conceivable generic type of dobj. This is because, even in an inline declaration in the position of an actual parameter, the rules for deriving the data type for a generically typed output parameter of a method apply. Here, the typing check allows fewer combinations than the conversion rules of an assignment.
  • Strings and internal tables are addressed internally using references. When assignments are made between strings and between internal tables of the same type (if the row type itself does not contain any table types), for performance reasons, only the internal administrative information is passed. After the assignment, the actual string or the actual table body of the source as well as the target object are addressed (sharing). Sharing is valid until the object is accessed to be changed. At this point, the sharing is canceled and a copy of the content is made. The sharing is displayed in the memory consumption display of ABAP Debugger and in the Memory Inspector tool. For internal tables where the row type itself contains internal table types, no sharing takes place. Sharing can, however, take place for the subtables with a certain row type.
  • If an internal table with a header line is specified as an operand of an assignment, in nearly all operand positions, the header line is addressed and not the table body. To address the table body of a table with a header line, [] must be appended to the table name.
  • The statement MOVE is an obsolete way of assigning data objects.


Example

Assigns a literal to a text string.

DATA text TYPE string. 

text = `blah`.

Example

Assigns a generically typed field symbol, <fs>, to a data object, number, declared inline. In the assignment, the field symbol has the type i, however the field number is created with the type decfloat34 when the program is generated. A syntax check warning about this is hidden using the pragma ##type.

FIELD-SYMBOLS <fs> TYPE numeric. 

ASSIGN 1 TO <fs>. 

DATA(number) = <fs> ##type.

Exceptions


Catchable Exceptions

CX_SY_CONVERSION_NO_NUMBER

  • Cause: Operand cannot be interpreted as number when assigned to a numeric data type
    Runtime Error: CONVT_NO_NUMBER

CX_SY_CONVERSION_OVERFLOW

  • Cause: Overflow in arithmetic operation (type p, with specified length)
    Runtime Error: BCD_FIELD_OVERFLOW
  • Cause: Operand too big or (interim) result too big
    Runtime Error: CONVT_OVERFLOW


Non-Catchable Exceptions

  • Cause: Source field (type p) contains an incorrect BCD format
    Runtime Error: BCD_BADDATA
  • Cause: Assignment for deep structures not allowed if they overlap
    Runtime Error: MOVE_COMPLEX_OVERLAP
  • Cause: Type conflict in assignment between object references
    Runtime Error: MOVE_INTERFACE_NOT_SUPPORTED,
    Runtime Error: MOVE_IREF_NOT_CONVERTIBLE,
    Runtime Error: MOVE_IREF_TO_OREF,
    Runtime Error: MOVE_OREF_NOT_CONVERTIBLE
  • Cause: Type conflict in assignment between data references.
    Runtime Error: MOVE_DREF_NOT_COMPATIBLE
  • Cause: Assignment between the involved types is not supported
    Runtime Error: MOVE_NOT_SUPPORTED
  • Cause: Constants and literals cannot be overwritten
    Runtime Error: MOVE_TO_LIT_NOTALLOWED
  • Cause: Constants and literals cannot be overwritten
    Runtime Error: MOVE_TO_LIT_NOTALLOWED_NODATA
  • Cause: During a loop on an internal table, an attempt is made to overwrite a reference variable that is associated with the internal table using REFERENCE INTO.
    Runtime Error: MOVE_TO_LOOP_REF