Internal Tables - Overview

What Are Internal Tables?

Internal tables are a way to store 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. The individual components of a row are also referred to as the columns of the internal table.

There are two kinds of internal tables in ABAP: data types and data objects. A data type returns the abstract description of an internal table and is used to create concrete data objects.

Data Types

Structures and internal tables represent the two structured data types available in ABAP (see ABAP Type Concept). The data type of an internal table is fully specified by:

• Row type
  The row type of an internal table can be any ABAP data type (that is, it can also be an internal table).

• Key
  The key is used to identify table rows. There are two possible keys for internal tables, the standard key and a user-defined key. The key can be defined as unique ( UNIQUE) or non-unique (NON-UNIQUE). If a key is unique, no multiple entries exist in internal tables. The uniqueness depends on the table type (see below).

• The standard key is made up of all non-numeric components of the associated row type that are no internal tables themselves or do not contain internal tables.

• The user-defined key can be made up of any components that are no internal tables themselves or do not contain internal tables, that is, do not have a deeply structured type. Internal tables with a user-defined key are called key tables. When you define the key, you must pay attention to the order of the key fields, which is important, for example, for sorting the data based on the key.

• Table type
  The table type determines how ABAP accesses individual table rows. Based on the table type, internal tables can be subdivided into the following three categories:

• In standard tables, a logical index is set up internally. The data can be accessed using the table index or the The response time for key-based access to standard tables increases linearly with the number of table entries. If key-based access is necessary, it makes particular sense to use standard tables if filling the table can be isolated from the other processing steps. For example, you can fill a standard table by appending rows and sort it afterwards. If you then use key-based access with the option for binary search (BINARY SEARCH addition), the response time depends only logarithmically on the number of the table entries.

• Sorted tables
  You use this table type if the table must be available in sorted form when it is set up. The table is then filled by inserting rows ( INSERT ... INTO TABLE) based on the sort order defined by the table key. The response time for key-based access depends logarithmically on the number of table entries, since a binary search is performed automatically. Sorted tables are also particularly useful for the partially sequential processing of a LOOP loop if the first parts of the table key are specified in the WHERE condition.

• Hash tables
  You use this table type if key-based access constitutes the central operation on table entries. Index-based access to hash tables is not possible. The response time for key-based access is always constant and does not depend on the number of table entries. As with database tables, the key of hash tables is always unique. Hash tables can therefore also be used to set up database-type internal tables and use them accordingly.

Declaring Internal Tables

Like any other ABAP data object, internal tables can first be created as a data type ( TYPES statement) and subsequently as a data object, or they can be directly declared as a fully specified data object ( DATAstatement). When you create an internal table as a data object, bear in mind that this only declares the administrative entry for an internal table as static. Unlike with all other ABAP data objects, the size of the memory space required is, however, not yet determined. The actual table rows are dynamically generated at runtime through operational fill statements and removed through delete statements.

When declaring an internal table, you can control the memory requirements of the table using the OCCURS and INITIALSIZE additions. This may affect the response times for filling the internal table (see the Performance Notes for Internal Tables).

Internal Tables as Parameters for Routines

Like any other parameter, internal tables can be passed by value or reference to subroutines and function modules.

If you want to pass a table together with its header line to a subroutine, you must pass it by reference using the TABLES addition. However, only STANDARDtables are allowed as TABLES parameters.

If a STANDARD table without a header line is passed as an actual parameter to a formal parameter with a header line (TABLES), the system automatically creates a header line in the routine. If you want to pass the body of a table with a header line as an actual parameter to a formal parameter without a header line, however, you can do this by using angle brackets after the name as described above.