Type of ABAB Internal Tables : SAP ABAB Tables

Categories: SAP

Standard Table

These are default table. The key of a standard table is always non-unique, so duplicates are allowed. DATA <ITAB> TYPE STANDARD TABLE OF <TY>. Record can be accessed through both INDEX and Condition.
READ TABLE <ITAB> INTO <WA> INDEX <N>. Or READ TABLE <ITAB> INTO <WA> WITH KEY <Condition>.

<ITAB> can be sorted Accessing/Searching time for the record depends on the No of Records because Searching is either Liner or Binary.

Sorted Table

Note: Records are always in sorted order. This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using INSERT statement. Entries are inserted according to the sort sequence defined through the table key. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Note: records can be accessed through both INDEX and with KEY(Condition). Note: Sorted Internal tables cannot be sorted again. Sorted internal tables are always either UNIQUE/ NON UNIQUE i.e. sorted internal tables cannot be declared without UNIQUE/NON-UNIQUE keyword. DATA <ITAB> TYPE SORTED TABLE OF <TY> WITH UNIQUE/NON-UNIQUE KEY <F1><F2>

Hashed Table

This is the most appropriate type for any table where the main operation is key access. Like database tables, hashed tables always have a unique key. DATA <ITAB> TYPE HASHED TABLE OF <TY> WITH UNIQUE/NON-UNIQUE KEY <F1><F2> You cannot access a hashed table using its INDEX. The response (Search) time doesnt depend on the number of records, instead it always remain constant regardless the number of table entries.

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.

Special features of Standard table

several release previously.

Sorted tables, hashed tables are only introduced in Release 4.0 standard tables already existed

Defining a line type, table type and tables without a header line have only been possible since Release 3.0. For this reason, there are certain features of standard tables that still exist for compatibility reasons. Standard table before Release 3.0 Before Release 3.0, internal tables all had header lines and a flat-structured line type. There were no independent table types. You could only create a table object using the OCCURS addition in the DATA statement, followed by a declaration of a flat structure: DATA: BEGIN OF <ITAB> OCCURS <n>, <F1> <F2> .. <FN> END OF <ITAB>. This statement declared an internal table <ITAB> with the line type defined following the OCCURS addition. Furthermore, all internal tables had header lines. The number <N> in the OCCURS addition had the same meaning as in the INITIAL SIZE addition from Release 4.0. Entering 0 had the same effect as omitting the INTIAL SIZE addition. In this case, the initial size of the table is determined by the system. Standard tables from Release 3.0 Since Release 3.0, it has been possible to create table types using

TYPES <T> TYPE|LIKE <linetype> OCCURS <n>. And table object using DATA <ITAB> TYEP|LIKE <linetype> OCCURS <n> [WITH HEADER LINE]. The effect of the occurs addition is to construct a standard tables with the data type <linetype>. The line type can be any data type. The above statement is still possible in Release 4.0, and has the same function as the following statement: TYPE <ITAB> TYEP|LIKE [STANDARD] TABLE OF <linetype>.

NOTE: OCCURS <0> allocates the initial memory 8kb and the system keep on allocated by 8kb, whenever it is required. OCCURS <N> allocates memory for <N> records initially and keep on allocates for <N> records, whenever it requires.