DATA

Variants

1. DATA f.
2. DATA f(len).
3. DATA: BEGIN OF rec,
...
END OF rec.
4. DATA: BEGIN OF itab OCCURS n,
...
END OF itab.
5. DATA: BEGIN OF COMMON PART c,
...
END OF COMMON PART.

Effect

Defines global and local variables. Variables allow you to address declared data objects . They always have a particular data type. Data types and data objects are important components of the ABAP/4 type concept .

Variant 1

DATA f.

Additions

1. ... TYPE typ
2. ... LIKE f1
3. ... TYPE typ OCCURS n
4. ... LIKE f1 OCCURS n
5. ... TYPE LINE OF itabtyp
6. ... LIKE LINE OF itab
7. ... VALUE lit
8. ... DECIMALS n
9. ... WITH HEADER LINE

Effect

Creates the internal field f in its standard length. If you do not specify the type (using the addition TYPE ), a field of type C is assumed.

The field f can be up to 30 characters long. You can use any characters you like except the special characters '(' , ')' , '+' , '-' , ',' and ':' . Numeric characters are allowed but the field name may not consist of numbers alone.

SPACE is a reserved word and therefore cannot be used. Also, the field name cannot be the same as one of the additional parameters of the introductory key word (e.g. PERFORM SUB USING CHANGING. ).

Recommendations for field names:
Always use a letter as the first character.
Use the underscore to join together words which are part of the same name (e.g. NEW_PRODUCT ). The hyphen should not be used here, since it is reserved for the names of field string components (see below).

Addition 1

... TYPE typ.

Effect

Creates a field f of the type typ . You can use either one of the predefined types listed below or one of your own types which you define with TYPES .
The standard length ( SL ) of the field depends on the type.

Type	Description	SL	Initial value
C	Text (character)	1	Blank
N	Numeric text	1	'00...0'
D	Date (YYYYMMDD)	8	'00000000'
T	Time (HHMMSS)	6	'000000'
X	Hexadecimal	1	X'00'
I	Whole number (integer)	4	0
P	Packed number	8	0
F	Floating point no.	8	'0.0'

Example


DATA NUMBER TYPE I.

Creates the field NUMBER as type I . You can also use it in the program, particularly if you want to assign number values and perform calculations.

Notes

The data type I is the whole number type on which the hardware is based. Its value range is from -2**31 to 2**31-1 (from -2.147.483.648 to 2.147.483.647).
You use type P for fields containing monetary amounts, but type I is more suitable for number fields, index fields, specifying positions and so forth.

You can use type F for positive and negative numbers other than zero in the range from 1E-307 to 1E+308 with a degree of accuracy up to 15 decimal places. (The ABAP/4 processor always uses the floating point operations of the hardware in question rather than standardizing them.) Floating point literals must be enclosed in quotation marks. The standard output length is 22.
Entries in type F fields may be formatted in any of the following ways:

As a decimal number with or without sign and with or without a decimal point.

In the form e, where you specify the mantissa as above and the exponent with or without a sign. (Examples of floating point literals: '1' , '-12.34567' , '-765E-04' , '1234E5' , '+12E+34' , '+12.3E-4' .

Since floating point arithmetic is fast on our hardware platforms, you should use it when you need a greater value range and you are able to tolerate rounding errors. Rounding errors may occur when converting the external (decimal) format to the corresponding internal format (base 2 or 16) or vice-versa (ABAP/4 number types ).

Addition 2

... LIKE f1

Effect

Creates the field f with the same field attributes as the field F1 which is already known. Any data objects are valid (fields, parameters, structures, ...) as long as types have been assigned.

f1 can be any Dictionary reference.

Example


DATA TABLE_INDEX LIKE SY-TABIX.

The field TABLE_INDEX now has the same attributes as SY-TABIX (the index for internal tables).

Note

This addition is often useful, since the ABAP/4 runtime system performs type changes on fields automatically. Any unnecessary and/or unwanted conversions are thus avoided.

Addition 3

... TYPE typ OCCURS n

Effect

Defines an internal table without header line. Such a table consists of any number of table lines with the type typ .
To fill and edit this table, you can use statements like APPEND , READ TABLE , LOOP and SORT .
The OCCURS parameter n defines how many tables lines are created initially. If necessary, you can increase the size later. Otherwise, the OCCURS parameter is of no significance, apart from the exception that applies with APPEND SORTED BY .

Example


TYPES: BEGIN OF LINE_TYPE,
         NAME(20) TYPE C,
         AGE      TYPE I,
       END OF LINE_TYPE.
DATA:  PERSONS    TYPE LINE_TYPE OCCURS 20,
       PERSONS_WA TYPE LINE_TYPE.
PERSONS_WA-NAME = 'Michael'.
PERSONS_WA-AGE  = 25.
APPEND PERSONS_WA TO PERSONS.
PERSONS_WA-NAME = 'Gabriela'
PERSONS_WA-AGE  = 22.
APPEND PERSONS_WA TO PERSONS.

The internal table  PERSONS  now consists of two table entries.

Note

Access to table entries not in main memory takes much longer. On the other hand, there is not enough space in main memory to hold such large tables because the roll area is resticted (see above).

Addition 4

... LIKE f1 OCCURS n

Effect

Defines an internal table without header line. Such a table consists of any number of table lines with the structure as specified by the data object f1 . Processing is the same as for addition 3.

Example


DATA:  BEGIN OF PERSON,
         NAME(20),
         AGE TYPE I,
       END OF PERSON.
DATA:  PERSONS LIKE PERSON OCCURS 20.

PERSON-NAME = 'Michael'.
PERSON-AGE  = 25.
APPEND PERSON TO PERSONS.
PERSON-NAME = 'Gabriela'
PERSON-AGE  = 22.
APPEND PERSON TO PERSONS.

The internal table  PERSONS  now consists of two table entries.

Addition 5

... TYPE LINE OF itabtype

Effect

The specified type itabtyp must be an internal table type. This operation creates a data object with the same line type as the table type specified.

Example


TYPES TAB_TYP TYPE I OCCURS 10.
DATA TAB_WA TYPE LINE OF TAB_TYP.

The data object TAB_WA now has the same attributes as a line of the table type TAB_TYP and thus the type I .

Addition 6

... LIKE LINE OF itab

Effect

The data object tab must be an internal table with or without a header line. This operation creates a data object with the same line type as the table specified.

Example


DATA TAB TYP TYPE I OCCURS 10.
DATA TAB_WA TYPE LINE OF TAB.

The data object TAB_WA now has the same attributes as a line of the table TAB and thus the type I .

Addition 7

... VALUE lit

Effect

The initial value of the field f is the literal lit instead of that defined in the table above. You can also specify a constant or even use IS INITIAL . In the latter case, the field is preset to the type-specific initial value. This form is particularly important in connection with the CONSTANTS statement which always requires you to use the addition VALUES .

Example


DATA NUMBER      TYPE I        VALUE 123,
     FLAG                      VALUE 'X',
     TABLE_INDEX LIKE SY-TABIX VALUE 45.

When created, the field NUMBER of type I contains 123 rather than the expected initial value of 0. The newly created field FLAG of type C (length 1) contains 'X' , while TABLE_INDEX contains 45, since the system field SY-TABIX is a numeric field.

Addition 8

... DECIMALS n

Effect

Only makes sense with field type P . When you perform calculations and on output, the field has n decimal decimal places, where n is a number between 0 and 14.

In the case of newly generated programs, you normally activate fixed point arithmetic in the attributes. If it is not set, the DECIMALS specification is taken into account on output, but not when performing calculations. This means that the programmer must take care of any decimal point calculations by multiplying or dividing by powers of ten. (see COMPUTE )
Fixed point arithmetic should always be active when you are performing calculations, since this enables intermediate results (for division) to be calculated as accurately as possible (in this case, to 31 decimal places).
To decide whether you should use the fixed point type P or the floating point type F , see "ABAP/4 number types ".

Addition 9

... WITH HEADER LINE

Effect

You can only use this addition with table types. When you specify WITH HEADER LINE , you create a header line with the same name type as a table line in addition to the table. With non-table operations (e.g. MOVE ), the name f refers to this header line. With table operations (e.g. APPEND ,
the name f refers to the table or the table and header line. The notation f[] always denotes the table. The result of this expression is a table without a header line and can be used as such.

Example


DATA:  BEGIN OF PERSON_TYPE,
         NAME(20),
         AGE TYPE I,
       END OF PERSON_TYPE.
DATA:  PERSONS LIKE PERSON_TYPE OCCURS 20 WITH HEADER LINE.

PERSON-NAME = 'Michael'.
PERSON-AGE  = 25.
APPEND PERSONS.
PERSON-NAME = 'Gabriela'
PERSON-AGE  = 22.
APPEND PERSONS.
* Delete header line
CLEAR PERSONS.
* Delete table
CLEAR PERSONS[].

Variant 2

DATA f(len).

Additions

As for variant 1

Effect

Creates the field f in the length len .

You can use this variant only for fields of type C , N , P and X . Any other field types must have their standard lengths (see table under effect of variant 1).

The lengths allowed depend on the field type:

Type	Allowed lengths
C	1 - 65535
N	1 - 65535
P	1 - 16
X	1 - 65535

Note

Each byte can contain (one character or) two decimal or hexadecimal digits. Since one place in type P fields is reserved for the sign, a type P field of length 3 can contain 5 digits, whereas a type X field of length 3 can hold 6 digits. Both have an output length of 6.

Variant 3

DATA: BEGIN OF rec,
...
END OF rec.

Effect

Defines the field string rec which groups together all the fields defined for the field string rec between " BEGIN OF REC " and " END OF rec ". Each field carries the prefix " rec- ". Field strings can be nested to any depth. See Data objects .
When a field string needs the same fields as an already defined field string in addition to its own fields, you can include these fields in the field string with INCLUDE STRUCTURE . If no additional fields are needed, it is better to use LIKE .

Example


DATA: BEGIN OF PERSON,
        NAME(20) VALUE 'May',
        AGE TYPE I,
      END   OF PERSON.
PERSON-AGE  = 35.

The field PERSON-NAME now contains the contents "May".


DATA: BEGIN OF PERSON1,
        FIRSTNAME(20) VALUE 'Michael'.
        INCLUDE STRUCTURE PERSON.
DATA  END   OF PERSON1.

Notes

If you list a field string as a field, this field (" rec ") is type C , but you should not use a field string like a field, if the field string contains number fields (i.e. type I , F or F ). The length of rec is derived from the sum of the lengths of all components of rec . However, since some fields (for example, to the limit of a word), they include padding fields that also contribute to the overall length of rec ; for this reason, you cannot use the lengths of fields that occur before a particular field string component to calculate its offset to the start of the field string. On the other hand, you can guarantee that two fields with the same structure always have the same structure (even where padding fields are concerned). This means that you can compare and assign fields directly below each other (with MOVE , IF , etc.) and do not have to work field by field (e.g. with MOVE-CORRESPONDING ).
INCLUDE s are aligned according to maxumum alignment of their components. This applies both to INCLUDE s in ABAP/4 programs and also INCLUDE s in Dictionary structures.

The TABLES statement automatically defines a field string (the work area. Even the header line belonging to an internal table (see below) is a field string.

Variant 4

DATA: BEGIN OF itab OCCURS n,
...
END OF itab.

Additions

... VALID BETWEEN f1 AND f2

Effect

Defines the internal table itab .

An internal table includes a header line, which is a field string containing the fields defined between " BEGIN OF itab OCCURS n " and " END OF itab " (see variant 3), and any number of table lines with the same structure as the header line.

To fill and edit an internal table, you use various statements such as APPEND , LOOP and SORT .

The OCCURS parameter n determines how many table lines are held in main storage (the roll area). If you also generate table entries, these are rolled out either to a main storage buffer or to disk (the paging area).

Example


DATA: BEGIN OF PERSONS OCCURS 20,
        NAME(20),
        AGE TYPE I,
      END   OF PERSONS.
PERSONS-NAME = 'Michael'.
PERSONS-AGE  = 25.
APPEND PERSONS.
PERSONS-NAME = 'Gabriela'.
PERSONS-AGE  = 22.
APPEND PERSONS.

The internal table now consists of two table entries.

PERSONS also includes the header line (work area) through which all operations on the actual table pass.

Note

Access to table entries not in main storage is considerably slower. Also, main storage cannot hold large tables in their entirety, since the size of the roll area is restricted (see above).

Addition

... VALID BETWEEN f1 AND f2

Effect

Can appear only after " END OF itab ".

The sub-fields f1 and f2 of the internal table itab must have the line-related validity range (see PROVIDE ).

Variant 5

DATA: BEGIN OF COMMON PART c,
.....
END OF COMMON PART.

Effect

Defines one or more common data areas in programs linked by external PERFORM calls. If only one common data area exists, you can omit the name c . There may be just one unnamed COMMON area or one or more named COMMON areas. You assign named COMMON areas to each other by name. The structure of data areas must always be the same for both the calling and the called program (otherwise, the program terminates with an error message at runtime).

The table work areas are always in the common data area.

In general, you define the area created as COMMON with a common INCLUDE STRUCTURE . Occasionally, you use a INCLUDE report which contains precisely the definition of the COMMON PART .

Field symbols cannot belong to a common data area, even if the FIELD-SYMBOLS statement lies between DATA BEGIN OF COMMON PART and DATA END OF COMMON PART .

Index
� SAP AG 1996