Intro to ABAP - Chapter 07

8/8/2019 Intro to ABAP - Chapter 07

http://slidepdf.com/reader/full/intro-to-abap-chapter-07 1/27

2.07.1

ASCENT - Strategic Initiative (SAP Development ABAP) Introduction to ABAP

SAP Release 4.6b Data Structures and Internal Tables

Version 2.0

Data Structures and Internal Tables



2.07.2



Version 2.0

Objectives



2.07.3



Version 2.0

Prior to the 4.0 release, program structures were simply called "field strings".

Structures

± Structures in code are similar to structures in the Dictionary in that they are simply field strings.

However, they are not dictionary objects but are temporary objects in program memory.

± Structures are used in connection with sequential datasets and

subroutines as well as a staging area for internal tables.

Internal Tables

± Internal tables are comprised of records which have the same format as an individual structure.

± Internal tables are tables which only exist during the execution of a program.

± Unlike the ABAP Dictionary transparent tables, internal table data

is not stored on the database server but resides in a program specific work area.

± Data can only be entered in an internal table by going through a staging area. A staging area can

either be a header line or a work area, either of which has the same structure as the internal table

itself.


http://slidepdf.com/reader/full/intro-to-abap-chapter-07 4/272.07.4



Version 2.0

Structures are defined with the DATA statement. The start and end of the structure are indicated by

BEGINOF <FSname> and END OF <FSname>.

Fields in a structure are defined as individual fields; you must specify the length and data type. You can

also define default values for components of structures. With the LIKE parameter, it is possible to adopt

the attributes of internal fields which have already been declared or the attributes of fields defined in the

ABAP Dictionary.

Reference fields in a structure as follows:

± <Structure>- <field name>e.g. YCUSTOMER-COUNTRY

It is possible to reference a complete structure ( WRITE: <structure>.). Note that the complete structure

is then considered as a field of type C. Type conversion does not take place. If the structure contained any

packed fields, the WRITE ADDRESS statement would not produce meaningful output.

A table work area defined in an ABAP program with the TABLES statement is comparable in

construction to a structure.

Note: Here the processing does not use the table TABNA, and so in this case the TABLES

statement is not required.



2.07.5



Version 2.0

A structure can also be defined using a combination of the TYPES and DATA statements.

± The TYPES statement defines a data type which in this example includes the fields: flag, id, name1,

and city. It does not allocate any memory for these fields.

± The DATA statement defines a variable using the data type defined with the TYPES statement. At

this point, memory is allocated and the structure is present in the program¶s work area.

This method is preferable to the previous one, especially when it comes to building an internal table from a

structure.



2.07.6



Version 2.0

Performance Tips:

MOVE-CORRESPONDING is less efficient than a specific MOVE statement for each field

In the work area/data structure. If the data structures f1 and f2 are the same and the sequence

and attributes of all fields are identical, you can just use the statement MOVE <f1> to <f2>

to transport the values of all fields from f1 to f2.

The statement MOVE-CORRESPONDING <f1> to <f2> transports values field by field between the

ABAP data structures f1 and f2 for all sub-fields with the same field names. The system searches in f1 for

all single fields that also occur in f2 and generates a statement for all pairs of fields found: MOVE <f1>-

<field name> TO <f2>-<field name>. The other fields remain unchanged.

The CLEAR statement resets all fields to their initial value. The data type initial values were covered in

chapter 1.04.01.



2.07.7



Version 2.0

We will see in the next few slides how to expand a structure into an object called an internal table, that can

store records of data temporarily during the processing of a program.

There are 3 different types of internal tables you can create: Standard, Sorted, and Hashed. The type of

table used determines the way in which the entries in the table are accessed by the system.

Standard tables are the same ones created in release 3. The time for key access to entries is in linear relation

to the number of entries in the table.

Sorted tables are ones that are always sorted correctly. The time for key access to entries is in logarithmic

relation to the number of entries in the table. This is because all accesses use a binary search.

Hashed tables are ones that contain records that all have a unique key. The time for key access to entries is

constant regardless of the number of entries in the table. This is because a hash algorithm is used to point to

any table entry instead of having to search for it (as in the Standard and Sorted cases). You can only use

key access to read entries in a hashed table. Index operations are not allowed.

When creating any of the internal table types, we have two further options:

± Defining a key

± Choosing between having the work area attached to or independent of the table.



2.07.8



Version 2.0

An internal table type is defined using the TYPES statement. No memory is allocated when defining a

type. Internal table names should always begin with IT_ .

An internal table object is created with the DATA statement by referring to an internal table type using

the TYPE parameter. It is this DATA statement that occupies memory. Internal table objects can also be

created through a reference to an existing table or structure using the LIKE parameter.

The programmer should define an INITIAL SIZE <n> parameter to indicate the initial number of table

lines for which memory will be allocated.

The above code creates a standard internal table IT_EMPTAB of structure EMP, and then loads the

employee data from table work area EMPLOYEE into the internal table header line of IT_ EMPTAB,

and then appends to the body of IT_ EMPTAB.

In previous versions, there was only one type of internal table, so the STANDARD TABLEOF

addition was not necessary. See the appendix for extended examples of older internal table

declaration styles. Also the INITIAL SIZE extension was called OCCURS. The old

declarations are still recognized in 4.x.



2.07.9



Version 2.0

By default, all the records that you append to your internal table have a key. This key is the combination of

all non-numeric fields. This is the implicit key.

You can also define your own key for an internal table. You would add WITH KEY FIELD1 FIELD2 «

etc. to your DATA statement.

More specifically, you can make your user-defined key:

± UNIQUE: additional records with the same key would not be permitted

± NON-UNIQUE: additional records with the same key would be permitted

Standard tables can have:

± NON-UNIQUE KEY (same as just plain KEY), or

± no user-defined key at all (more likely)

Indexing is used more than keys when it comes to reading standard internal tables.

User-defined keys are new as of 4.0. You would only be able to use the implicit key in previous releases.



2.07.10



Version 2.0

Performance Tips:

If you know the maximum size of an internal table and that size is less than 8K, you can increase

the system¶s performance by specifying the maximum size in the INITIAL SIZE <n> parameter.

If you do not know the maximum size of an internal table or if it¶s greater than 8K, you should let

the system allocate the appropriate memory by specifying INITIAL SIZE 0 in the internal tabledefinition. Any table larger than 8K should be declared INITIAL SIZE 0.

INITIAL SIZE <n> parameter: With <n>, you specify an initial number of lines for the internal table.

For the number of lines specified, memory will be reserved as soon as the first line is written into an

internal table.

If more lines are added to an internal table than specified by <n>, the reserved memory will expand

automatically. Therefore, it is possible to create an internal table with the parameter INITIAL SIZE 0. If

there is not enough storage in memory for the internal table, it will be written into a buffer or on a disk

(paging area).

If the INITIAL SIZE parameter is left off, a value of INITIAL SIZE 0 is set.

The INITIAL SIZE parameter will affect the physical size of an internal table if the APPEND <Internal

table> SORTED BY <field> statement is used to load data into the internal table (see next slide).



2.07.11



Version 2.0

The OCCURS parameter on the DATA statement can be used to define an internal table. This method of

creating an internal table performs three functions with this one statement:

± it identifies the size of an internal table just like the INITIAL SIZE # option

± it creates an internal table object

± automatically creates a header line for the internal table

The structure of the internal table is defined between the BEGIN OF <itab>« and END OF <itab>. This

method of creating an internal table does not use the TYP

ES statement to identify the structure of theinternal table.

It is this DATA statement that occupies memory. When records are inserted into an internal table the the

SAP system allocates a memory space of approximately 8 to 16 K in a block.

If the data to be read is estimated to be under 8K, an estimate of the number of lines used in the OCCURS/

INITIAL SIZE parameter helps in effectively using the memory space. Therefore, if you know the

maximum size of your internal table then you should specify a number. Otherwise, use 0.

The above code creates a standard internal table IT_EMPTAB of structure EMP, and then loads the

employee data from table work area EMPLOYEE into the internal table header line of IT_ EMPTAB, and

then appends to the body of IT_ EMPTAB.





2.07.13



Version 2.0

In the first example, the table entries are saved in the sequence in which they are read. More than ten

entries can be saved.

In the second example, the table entries are sorted by the field salary in descending order. A maximum of

ten table entries are saved.

With an APPEND <internal table> SORTED BY <field> statement, the number of entries in the table

exceeding the value of the INITIAL SIZE clause are deleted. Normally, it is better to use an external

SORT (covered in a later slide).



2.07.14



Version 2.0

REPORT Y170DM38.

A TABLES: EMPLOYEE.

TYPES: BEGIN OF EMP,

ID LIKE EMPLOYEE-ID,

NAME1 LIKE EMPLOYEE-NAME1,

COUNTRY LIKE EMPLOYEE-COUNTRY,

END OF EMP.

B DATA: IT_EMP

TAB TYP

E STANDARD TABLEOF

EMP

INITIAL SIZE 10 WITH HEADER LINE.

SELECT * FROM EMPLOYEE.

MOVE-CORRESPONDING EMPLOYEE TO IT_EMPTAB.

APPEND IT_EMPTAB.

ENDSELECT.

B

A



2.07.15



Version 2.0

REPORT Y170DM38.

TABLES: EMPLOYEE.





END OF EMP.

DATA: IT_EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 WITH

HEADER LINE.

1 SELECT * FR OM EMPLOYEE.


APPEND IT_EMPTAB.

ENDSELECT.

1



2.07.16



Version 2.0

REPORT Y170DM38.

TABLES: EMPLOYEE.





END OF EMP.

DATA: IT_EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 WITH HEADER

LINE.



APPEND IT_EMPTAB.

ENDSELECT.

1

2



2.07.17



Version 2.0

REPORT Y170DM38.

TABLES: EMPLOYEE.





END OF EMP.


HEADER LINE.



APPEND IT_EMPTAB.

ENDSELECT.

1

2

3



2.07.18



Version 2.0

REPORT Y170DM38.

TABLES: EMPLOYEE.





END OF EMP.


HEADER LINE.

SELECT * FR OM EMPLOYEE.


APPEND IT_EMPTAB.

ENDSELECT.

4

5

6



2.07.19



Version 2.0

To create an internal table without a header line, the programmer must:

± Create an internal table data type with the TYPES statement. This type will become the structure of

the internal table.

± Once the TYPE is created, a DATA statement is coded to identify the actual internal table object

without the WITH HEADER LINE clause. The internal table inherits the fields and attributes from

the TYPES statement defined earlier.

± In addition, the programmer must also define an internal table work area (staging area). This work

area is defined using the same format as the internal table. It uses the same user-defined data type asthe internal table.

The work area is loaded programmatically (i.e., MOVE-CORRESPONDING EMPLOYEE TO

IT_EMPTAB_WA), then appended to the internal table.

To load an internal table without a header line, the following APPEND statement is used:

± APPEND <work area> to <internal table>.



ASCENT St t i I iti ti (SAP D l t ABAP) I t d ti t ABAP



2.07.21



Version 2.0

REPORT Y170DM40.

TABLES: EMPLOYEE.





END OF EMP.

DATA: IT_EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 ,

IT_EMPTAB_WA TYPE EMP.


MOVE-CORRESPONDING EMPLOYEE TO IT_EMPTAB_WA.

APPEND IT_EMPTAB_WA TO IT_EMPTAB.

ENDSELECT.

A

B

ASCENT Strategic Initiative (SAP Development ABAP) Introduction to ABAP



2.07.22



Version 2.0

REPORT Y170DM40.

TABLES: EMPLOYEE.





END OF EMP.

DATA: IT_EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 ,

IT_EMPTAB_WA TYPE EMP.

SELECT * FR OM EMPLOYEE.

MOVE-CORRESPONDING EMPLOYEE TO IT_EMPTAB_WA.

APPEND IT_EMPTAB_WA TO IT_EMPTAB.

ENDSELECT.

1

2

3




2.07.23

ASCENT Strategic Initiative (SAP Development ABAP) Introduction to ABAP


Version 2.0

The example above demonstrates how to create an internal table that gets its structure from an existing

table/structure in the ABAP Dictionary (in this example, EMPLOYEE). This is a very valuable capability.

Referencing other previously defined structures can save time (not having to code them) and problems.

The only difference between making an internal table from a TYPES statement or from an existing

dictionary structure, is the use of the word TYPE or LIKE in the DATA declaration.

It is also possible to refer to other objects defined in the program.

Notice the use of MOVE instead of MOVE-CORRESPONDING. The MOVE statement is used because

the structure of IT_EMPTAB is identical to the structure of EMPLOYEE.

The above code loads the EMPLOYEE data into the internal table IT_EMPTAB. It does not process the

internal table (this will be covered in later slides).




2.07.24

g ( p )


Version 2.0

When a MOVE-CORRESPONDING is performed, type conversion occurs automatically for the

individual fields. The process is carried out on a field-by-field basis. MOVE specified field to specified

field behaves the same way.

However, the following three scenarios are handled similarly to each other:

± when you MOVE a structure to a structure of a different definition

± MOVE a field to a structure

± a structure to a field

In these cases, the data would be converted to one long character string (type C) first, then conversion

would take place.

If a piece of data is moving to a longer space in the new structure, it will be padded with spaces or zeroes

according to its data type. Moving into a shorter length would cause truncation.

Structures with an internal table included as a component do not follow the typical rules.

See Online Help for extended information about all the data conversion rules.




2.07.25

g ( p )


Version 2.0

To read records from a database table directly into an internal table, you need a basic SELECT * FR OM

<database> statement with one of the following variations:

± INTOTABLE <internal table>

± APPENDING TABLE <internal table>

The INTO TABLE <internal table> addition fills the internal table with the selected database records.

Any old entries in the internal table are overwritten.

The APPENDING TABLE <internal table> appends the selected database records to any existing

entries in the internal table.

The database records are placed in the internal table IT_EMPTAB in a single operation rather than one-

by-one as in a basic SELECT processing loop.

Since no loop processing occurs, no ENDSELECT is needed.

The WHERE andORDER BY additions are optional.

The internal table must be at least as wide as the database table. Records are placed in the internal table

left-justified (i.e., starting from the first field listed in the definition of the internal table), so any additional

field(s) you want in the internal table must be the last field(s) defined beyond the width of the database

table.

Coding Recommendations:

The addition INTOCORRESPONDING FIELDSOF TABLE <itab> can be used.




2.07.26


Version 2.0

A work area (staging area) is required when working with an internal table without a header line. This

work area is defined as a Structure with the same structure as the internal table. The work area is loaded

and the table is processed from the work area.

A summary of the statements used for internal tables without header lines is

the following:

± APPEND <work area> TO <internal table>

Appends the contents of the work area to the end of the internal table

± COLLECT <work area> INTO <internal table>

Accumulates the values on a field into the table

± INSERT <work area> INTO <internal table>

Inserts a new line with the contents of the work area before the

current line

± MODIFY <internal table> FROM <work area>

Overwrites a line in the table with the contents of the work area

± READ TABLE <internal table> INTO <work area>

Reads a line from the table into the work area

± LOOPAT <internal table> INTO <work area>

Processes an internal table. On each loop pass, a table entry is placed in the work area




2.07.27


Version 2.0

Summary

Documents

Intro to ABAP - Chapter 07