1. MOVE f
TO g.
2. MOVE
f+off1(len1) TO g+off2(len2).
3.
MOVE meth( ... ) TO g.
4.
MOVE o1 ?TO o2.
5. MOVE c1 TO c2 PERCENTAGE n.
MOVE f TO g.
In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs. See Assignments and Dynamic Field Assignments.
Moves the contents of field
f to field g.
Field f remains unchanged.
This statement is equivalent to:
g = f.
DATA: NUMBER TYPE I,
FIVE TYPE I.
MOVE 5 TO FIVE.
MOVE FIVE TO NUMBER.
The fields NUMBER and FIVE now both have the value 5.
MOVE f+off1(len1) TO g+off2(len2).
In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs. See Offset/Length Access and Unicode.
With offset
off2 and length len2,
field
g receives the contents of field f with offset
off1 and length len1.
The offset and length specifications can also be variable.
The target field must not be of type
STRING or XSTRING, if you use offset and length declarations.
DATA: FIELD1(10) VALUE '1234567890',
OFF1 TYPE I VALUE 1,
LEN1
TYPE I VALUE 2,
FIELD2(8) VALUE 'abcdefgh',
OFF2
TYPE I VALUE 3,
LEN2 TYPE I VALUE 4.
MOVE FIELD1+OFF1(LEN1) TO FIELD2+OFF2(LEN2).
FIELD2 now has the value 'abc23 h'.
MOVE meth( ... ) TO g.
You can replace the source field in a MOVE statement with
a functional method call. Functional methods are methods in ABAP Objects
that can have any number of IMPORTING parameters but have exactly one RETURNING parameter.
Depending on the number of IMPORTING parameters, the following options are available:
In variants 2 and the CALL METHOD statement is used to pass the actual parameters to the method's IMPORTING parameters.
When the system executes the MOVE statement, it calls the method meth and assigns this method's return values to the target field g.
CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS M1 RETURNING VALUE(R)
TYPE I.
METHODS: M2 IMPORTING N TYPE I
RETURNING VALUE(R) TYPE I,
M3
IMPORTING N1 TYPE I
N2 TYPE I
RETURNING VALUE(R) TYPE I.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD
m1.
r = 100.
ENDMETHOD.
METHOD m2.
r
= 10 * n.
ENDMETHOD.
METHOD m3.
r = n1 +
n2.
ENDMETHOD.
ENDCLASS.
DATA: oref TYPE REF TO c1,
number1
TYPE i VALUE 3,
number2 TYPE i VALUE 5,
result TYPE
i.
START-OF-SELECTION.
CREATE OBJECT oref TYPE c1.
MOVE C1=>M1(
) TO RESULT.
WRITE / RESULT.
MOVE oref->m2( number1 ) TO result.
WRITE
/ RESULT.
RESULT = OREF->M3( N1 = NUMBER1 N2 = NUMBER2 ).
WRITE / RESULT.
MOVE o1 ?TO o2.
Casting between Reference variables (Widening Cast).
This statement is equivalent to:
o2 ?= o1.
The fields o1 and o2 must be reference variables - that is, of type REF TO. Otherwise, the system triggers the exception that can be handled MOVE_CAST_REF_ONLY . You should always perform casting if you are making an assignment between reference variables and there is no static type check during the syntax check. If a static type check does take place, you can use the normal MOVE statement or the assignment operator (=).
If the assignment is between two reference variables for which the type of the target variable can only
have the same number of components as or fewer components than the source variable, then static type
checks can take place. Conversely, if the assignment is between two reference variables for which the
type of target variable has more components than the source variable, no type check can take place.
When you use casting, the system checks at runtime to see whether or not the reference in the
source variable points to an object to which the reference in the target variable can also point. If
an assignment is possible, it will take place. If not, this raises the exception that can be handled MOVE_CAST_ERROR.
If the source variable is an object reference and initial, its dynamic type is handled like the empty class OBJECT, and no exception is raised.
INTERFACE I1.
DATA A.
ENDINTERFACE.
CLASS C1 DEFINITION.
PUBLIC
SECTION.
INTERFACES I1.
ENDCLASS.
CLASS C2 DEFINITION.
PUBLIC
SECTION.
DATA A.
ENDCLASS.
DATA: ROOT TYPE REF TO OBJECT,
R1
TYPE REF TO I1,
O1 TYPE REF TO C1,
O2
TYPE REF TO C1,
O3 TYPE REF TO C2.
CREATE OBJECT O1.
ROOT = O1. "Static assignment possible
ROOT ?= O1. "Casting
does the same as static assignment
CATCH SYSTEM-EXCEPTIONS MOVE_CAST_ERROR = 4.
MOVE
ROOT ?TO O2. "Only casting possible
ENDCATCH.
IF SY-SUBRC NE 4.
O2->I1~A
= 'X'.
ENDIF.
R1 = O1. "Static assignment possible
R1 ?= O1. "Casting
does the same as static assignment
CATCH SYSTEM-EXCEPTIONS MOVE_CAST_ERROR = 4.
O1
?= R1. "Only casting possible
ENDCATCH.
IF SY-SUBRC = 0.
WRITE
/ 'Casting O1 ?= R1 successful!'.
ENDIF.
CATCH SYSTEM-EXCEPTIONS MOVE_CAST_ERROR = 4.
O3
?= R1. "Only casting possible
ENDCATCH.
IF SY-SUBRC = 4.
WRITE / 'Casting O3 ?= R1 not successful!'.
ENDIF.
MOVE c1 TO c2 PERCENTAGE n.
1. ... LEFT
2. ... RIGHT
This variant is not allowed in an ABAP Objects context. See Cannot Use MOVE PERCENTAGE.
c1 and c2
must be type C fields; n is a field with a numeric value
between 0 and 100. The left part of field
c1 (n percent)
is moved to field c2 and is left-justified. c2 is filled with blanks if necessary.
... LEFT
This is the default. With this statement, you can clearly state that transfer is to be left-justified.
... RIGHT
Transfer is right-justified, the left part of field c1, as in the default.
Performance:
The runtime required to transfer a C(1) field to a C(1) field is 1 msn
(standard microseconds).
Conversions should be avoided for performance reasons, that is the fields
should have the same type and length. For example, a MOVE
of a C(10) field to a C(10) field requires about 2 msn, while a MOVE of a C(10) field to a type I field needs about 10 msn.
Catchable Exceptions
CX_SY_CONVERSION_NO_NUMBER
CX_SY_CONVERSION_OVERFLOW
CX_SY_MOVE_CAST_ERROR
Non-Catchable Exceptions
Assigning Values with MOVE
Handling Objects