Internal Tables

Internal tables are a way to store variable datasets of a fixed structure in the working memory of ABAP. The data is stored on a row-by-row basis, where each row has the same structure.

Internal tables provide the functionality of dynamic arrays and relieve the programmer of the expenditure of a program-controlled dynamic memory management (see Memory management of deep data objects. Internal tables are preferably used to store and format the content of database tables from within a program. Furthermore, internal tables in connection with structures are the most important means of defining very complex data structures in an ABAP program.

Data Type of an Internal Table

A table type defined in the ABAP Dictionary or using TYPES or DATA is fully specified by:

• Row Type
  The row type of an internal table can be any data type. If the row type is structured, the individual components of a row are called columns of the internal table.

• Table Category
  The table category defines how an internal table is managed and how the individual rows can be accessed. There are three table categories:

• Standard tables are managed internally by a table index which may be realized by means of a logical index. Access is possible via table index or table key. With a key access, the response time is directly dependent on the number of table entries. The key of a standard table is always non-unique.

• Sorted tables are managed internally by means of a table index, too. They are always sorted by the table key and can be accessed via the table index or the table key. With a key access, the response time is logarithmically dependent on the number of table entries, because the table is accessed via a binary search. The key of sorted tables can be unique or non-unique.

• Hashed tables are managed internally by a hash algorithm. Hashed tables can be accessed only via the table key. The repsponse time is constant, independent of the number of table entries. The key of hashed tables is always unique.

• Table Key
  The table key is required for the identification of table rows. There are two possible keys for internal tables, the standard key and a user-defined key. The key can be declared as unique or non-unique, depending on the table category. With unique keys, a row with a particular content in the key fields can occur only once in the internal table. A user-defined key can consist of components of the row type or of the entire row ( pseudo component table_line), provided they do not contain or are no internal tables. When defining the key, the sequence of the key fields is significant. A table type defined in the ABAP Dictionary or with TYPES needs not be fully specified, in contrast to all other data types. In the definition, either only the key or the row type and the key can remain unspecified. Such a type is generic and can be used exclusively for the typing of field symbols and formal parameters. For this, also the predefined generic ABAP types ANY TABLE and INDEX TABLE exist. The first includes all table types, the second inlcudes the standard and sorted tables, the so-called index tables.

Like strings, internal tables are dynamic data objects. As far as row type, table category and table key are concerned, they are always fully specified, but with any number of rows, which is limited only by the capacity limits of the actual system installations (see Maximum size of dynamic data objects).

Accessing Internal Tables

When accessing internal tables, you can address either the entire table or table body or individual rows.

To access the table body, you use special statements such as SORT, but also general statements such as MOVE. To access individual rows, you use special statements such as READ_TABLE, LOOP AT or MODIFY. When accessing individual rows, you either use a work area into which the row content can be read or where it can be modified, or you link a row to a field symbol or a data reference variable and use it to access the row directly.

Notes

• If the row type of internal tables contains object reference variables as components comp, then the attributes attr of the object to which the reference of a row points can be used as key values for reading, sorting and changing table rows. This is basically possible with statements in which individual components of the table are addressed.

• With all modifying accesses to individual rows of sorted tables and hashed tables, the content of the table key must not be changed.

Selecting the Table Category

Which table category to use depends on which kind of access to individual rows will be applied most frequently for the table.

• Standard Tables
  This table category is suited best whenever the individual entries can be accessed using the index. The index access is the fastest access to table entries. You should fill a standard table by appending rows with APPEND and execute the other accesses by specifying an index (addition INDEX of the resprective statement). Since the expenditure for key accesses to standard tables increases directly with the number of table entries, you should use key accesses to standard tables only if you can decouple the filling of the table from the other processing operations. If a standard table is sorted after the filling, a key access with binary search (BINARY SEARCH) is connected to the number of table entries only logarithmically.

• Sorted Tables
  This table category is suited whenever the table must already be sorted when it is filled. You then use INSERT to fill the table according to the sort sequence defined by the table key. With key accesses, the expenditure is connected logarithmically to the number of table entries, because a binary search is carried out automatically. Sorted tables are suited for partly sequential processing in a LOOP if the beginning of the table key is specified in the WHERE condition.

• Hashed Tables
  This table category is suited whenever the key accessess represent the central operation on the table entries. With hashed tables, no index access is possible. With key accesses, the expenditure is always constant and independent of the number of table entries. Like with database tables, the key of a hashed table is always unique. Therefore, hashed tables are also suited as database-type internal tables.

Internal Tables with Header Lines

Outside of classes and as long as an internal table is not a component of a structure or row of another internal table, you can create an internal table with a so-called header line (HEADER LINE). A header line is a work area whose data type is the row type of the internal table and whose name is the name of the internal table. You should not use this possibility, because then two data objects with the same name exist in the ABAP program. Instead of a header line, you can simply create an explicit work area using the addition LINE OF of the statements TYPES, DATA etc.

The statements for the access to individual rows use the header line as implicit work area if no explicit work area is specified. In all other cases it depends on the statement and operand position whether the table body or the header line is used for processing when you specify a table name. Usually the header line is addressed. To force access to the table body, you can specify square brackets after the name (for example, itab[]). When passing it to table parameters, table body and header line are passed.