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 forme , 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
좋은정보 감사합니다.^^