write to & move

[Former Member]

hai all...

can any one say me what is the difference between 'write to' and 'move' statements.

Data : a(5) type c value 'ABAP',

b(5) type c .

write a to b.

move a to b.

what is the difference between both the statements given above.

will be rewarded if helpful..

Thanks & Regards,

Jhansi.

[anversha_s]

hi,

While using the MOVE statement the source field & the target field should be of the same type or should be type convertible & compatible.

example ;

data : source type i value 100,

target type i.

move source to target.

In the case of WRIE TO the source field can be of any type but the target field should always be a character type.

example ;

data : source type i value 200,

target(10) type c.

write source to target.

Todays date is 23.nov.2006. (sy-datum)

Move :---> 20061122

Write :----> 23.11.2006

chk this

report zabc.

DATA : STR(15) TYPE C.

MOVE SY-DATUM TO STR.
WRITE:/ STR.
WRITE SY-DATUM TO STR.
WRITE:/ STR.

Rgds

Anver

[Former Member]

Hi,

MOVE doesn't invoke conversion routines

WRITE will invoke conversion routines..

Thanks,

Naren

[Former Member]

Hi

we should use 'write to' when we need the effect of outputting the variable to list output. (well thats what the documentation says).

U might wonder what the difference is.. suppose we use these methods on a field with conversion exit, it will be clear. Using 'write to', the value is converted using the conversion exit while it is not the case with move.

refer.

-charitha

[Former Member]

Hi,

Write To

1. WRITE f TO g[+off][(len)].

2. WRITE f TO itab[+off][(len)] INDEX idx.

Variant 1

WRITE f TO g[+off][(len)].

Addition

... option

Effect

Assigns the contents of the source field f to the target field g as a new value.

In contrast to MOVE , the format of the target field g is the same as when outputting to a list with WRITE . The field type C is always used, regardless of the actual data type.

As with list output, the settings in the user's master record for decimal point (period or comma) and date format are taken into account.

Other formatting options are also possible with list output.

Instead of specifying a static source field f , you can make a dynamic source field specification (name) . In this case, the contents of the field name is interpreted as the source field name at runtime and the contents are formatted accordingly.

You can identify the target field g more precisely by specifying the offset and/or length in the form g+off(len) . Both the offset and the length specifications off and len can also be dynamic.

The return code value SY-SUBRC is undefined.

Example

WRITE ... TO with dynamic source field specification and dynamic offset and length specification for the target field:

DATA: NAME(5) VALUE 'FIELD',

FIELD(5) VALUE 'Harry',

DEST(18) VALUE 'Robert James Smith',

OFF TYPE I,

LEN TYPE I.

OFF = 7.

LEN = 8.

WRITE (NAME) TO DEST+OFF(LEN).

The field DEST noew contains the value " Robert Harry ith ".

MOVE

Variants

1. MOVE f TO g.

2. MOVE foff1(len1) TO goff2(len2).

3. MOVE c1 TO c2 PERCENTAGE n.

Variant 1

MOVE f TO g.

Effect

Moves the contents of field f to field g . Field f remains unchanged.

This statement is equivalent to:

g = f.

Example

DATA: NUMBER TYPE I,

FIVE TYPE I.

MOVE 5 TO FIVE.

MOVE FIVE TO NUMBER.

The fields NUMBER and FIVE now both 5.

Notes

Multiple assignments like

NUMBER = FIVE = 5.

are also possible. ABAP/4 executes them from right to left (as in the above example).

If the field types or lengths differ, type conversion follows automatically. Type I fields are handled like type P fields. If you select the fixed point arithmetic attribute for an ABAP/4 program, type P fields are either rounded according to the number of decimal places or filled with zeros.

In contrast to WRITE TO , the decimal character is always a period (.), regardless of the specification in the user master.

MOVE allows you to copy tables and structures which contain other tables.

Two tables can be copied only if this is possible for their respective lines. If the line types are incompatible, conversions are performed line by line. If itab is a table with a header line, the table itself can be addressed with itab[] .

Two structures which themselves contain tables can only be copied if they are compatible (i.e. if the ABAP/4 type check allows this).

Conversion table ( f -> g ) depending on the types of f and g :

C -> C Left-justified transfer. If the target field is longer than the source field, it is padded with blanks on the right. If it is shorter than the source field, the left part of the source field is copied and the rest is truncated. C -> D The field f must be an 8-character date in YYYYMMDD format. C -> F The character string in f must be a valid representation of a floating point number (DATA ). C -> N Only the digits in f are valid here. They are moved to g , right-justified and padded with zeros on the left. If the target field is too short, digits on the left are truncated. C -> T The field f must contain a 6-character time specification in HHMMSS format. C -> P the field f must contain a decimal number, i.e. a sequence of numeric characters with optional signs and more than once decimal point; there may be blanks on either side. If g is too short, an overflow error can occur. C -> X The field f must contain a hexadecimal character string (i.e. the only valid characters are 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). The number to be converted is treated as a hexadecimal number rather than a decimal number,

e.g.: C'15' -> X'15' .

It is transported left-justified to g and either padded with zeros or truncated,

e.g.: C'AB' -> X'AB00' .

f is processed up to the first blank.

Examples:

C'ABC' -> X'ABC0', C'ABC0' -> X'ABC0'

C'ABC D' -> X'ABC0', C' AB' -> X'0000'

D -> C Left-justified transfer without conversion D -> D Transfer without conversion D -> F As for D -> P and then P -> F D -> N As for D -> C and then C -> N D -> P Inverse of P -> D D -> T Not supported: Error message D -> X Inverse of X -> D

F -> C f is converted to E format and moved to g . E.g.: F'-3.142' -> C'-3.14200000000000E+00'

If the mantissa is unequal to 0, it is standardized so that it lies between 1.0 and 9.99...

The exponent is generally 2-digit; it is only converted to 3-digit format if it is greater than 99 or smaller than -99

The exponent always appears with a sign.

If g is too short, the mantissa is rounded.

e.g.: F'3.152' -> C' 3.2E+00' .

The length of g should be at least 6, otherwise it g is filled with asterisks (*). F -> D See F -> N F -> F Transfer without conversion F -> N f is rounded as with F -> P and then treated like a P field. F -> P f is rounded, e.g. F'-3.512' -> P'-4' . F -> T See F -> N F -> X See F -> N

N -> C f is treated like a C field; leading zeros remain. N -> D As for N -> C and then C -> D N -> F As for N -> P and then P -> F N -> N Right-justified transfer; on the left, padded with zeros or truncated. N -> P f is packed and moved to g with a positive sign (+). If g is too short, an overflow error can occur. N -> T As for N -> C and then C -> T N -> X As for N -> P and then P -> X

P -> C f is moved to g with a trailing sign and, if required, a decimal point.

e.g.: P'-1234567' -> C'12345.67-'

Notes:

1) One position is always reserved for the sign and, in the event of a positive number, a blank is output.

2) Leading zeros are output as blanks.

3) If g is too short, the blank representing the sign in the case of positive numbers is omitted; if this is insufficient, the number is truncated on the left - this is indicated by an asterisk (*).

Examples (the P field f has the length 2, the C field g the length 3):

P'123' -> C'123', P'-123' -> C'*3-'

4) If you do not want to reserve a position for the sign, use the WRITE TO statement with the addition NO-SIGN .

5) To convert with leading zeros and without formatting characters, use the UNPACK statement. P -> D The value in f is the absolute date (i.e. the number of days since 01.01.0001) and is moved to g in the YYYYMMDD format. This takes into account that the Julian Calendar was replaced by the Gregorian Calendar on 15.10.1582. The value 0 (and negative values) are transferred into the initial date '00000000'. P -> F The field f is moved to g as a floating point number. P -> N Right-justified transfer without sign; padded with zeros on the left. P -> P If g is too short, an overflow error can occur. P -> T The value in f is an absolute time (i.e. the number of seconds since midnight modulo 24 hours = 86.400 seconds) and is moved to g in HHMMSS format. P -> X The value in f is stored in g as a hexadecimal number. E.g.: P'15' -> X'0F' .

Negative numbers are represented by the two's complement.

e.g.: P'-153' -> X'FF67' .

If the length of g is greater than 4, only the last 4 Bytes are provided for according to the value of f ; the Bytes before them are padded with Hex-0.

If g is too short, the number is truncated on the left.

T -> C As for D -> C T -> D Not supported: Error message T -> F As for T -> P and then P -> F T -> N As for T -> C T -> P Inverse of P -> T T -> T Transfer without conversion T -> X Inverse of X -> T

X -> C f is converted to hexadecimal format. The result is transferred left-justified and padded with blanks or truncated on the right.

e.g.: X'0F' -> C'0F' X -> D The value in f is an absolute date (number of days since 01.01.0001) and is moved to g in YYYYMMDD format. (See also P -> D.) X -> F As for X -> P and then P -> F X -> N As for X -> P and then P -> N X -> P f is treated as a hexadecimal number and moved to g in decimal packed format.

e.g.: X'0F' -> P'15'

If f is longer than 4, only the last 4 bytes are processed.

If g is too short, an overflow error can occur. X -> T The value in f is an absolute time (i.e. the number of seconds since midnight modulo 24 hours = 86,400 seconds) and is moved to g in HHMMSS format. (See also P -> T.) X -> X Left-justified transfer; padded with X'00' on the right or truncated.

Regards

Shiva

[Former Member]

Hi Jhansi,

The basic differnce between 'move to' and 'write to' is dat .

'move to' wil perform type conversion if source and target fields are not of the same type .

whereas 'write to' does not perform any type conversion .

it assumes target field to be of type c only .

so wen using write to u can get garbage values if source and target are not of type c .

check this program.

DATA : STR(15) TYPE C.

*----

---

MOVE SY-DATUM TO STR.

WRITE:/ STR.

WRITE SY-DATUM TO STR.

WRITE:/ STR.

output.

Move :---> 20061122

Write :----> 22.11.2006

Regards,

Priyanka.