Data structure that exists only at program run time.

Internal tables are one of two structured data types in ABAP. They can contain any number of identically structured rows, with or without a header line.

The header line is similar to a structure and serves as the work area of the internal table. The data type of individual rows can be either elementary or structured.

Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP.

The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs.

You should use internal tables whenever you want to process a data set with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.

Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects.

A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.



This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index.

The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.

Hashed tables have no linear index.

You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.


The operations listed below are only permitted for index tables (sorted and standard tables). Some of them are restricted to standard tables.

Since it is quicker to access a table by index than by key, you should always use specific index operations when you know that a particular internal table is an index table.

In particular, the quickest way to fill a table line by line is to append lines to a standard table, since a standard table cannot have a unique key and therefore appends the lines without having to check the existing lines in the table.

If you can either accommodate duplicate entries in a table, or exclude them in a different way, it can be quicker to fill a standard table and then sort it or assign it to a sorted table if the data does not have to be inserted into the table in the correct sort sequence.

Furthermore, the performance of operations that change the internal linear index has been improved in Release 4.5A. Previously, index manipulation costs for inserting and deleting liens in standard tables and sorted tables increased in linear relation to the number of lines.

From Release 4.5A, the index manipulation costs only increase logarithmically with the number of lines, since the table indexes are now maintained as a tree structure. This makes insertion and deletion operations efficient, even in very large standard and sorted tables.


This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement.

Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table.

The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.

Related questions