Types of internal tables

What Are Different Types Of Internal Tables and Their Usage

Standard Internal Tables
Standard tables have a linear index. You can access them using either the index or the key. If you use
the key, the response time is in linear relationship to the number of table entries. The key of a
standard table is always non-unique, and you may not include any specification for the uniqueness in
the table definition.
This table type is particularly appropriate if you want to address individual table entries using the
index. This is the quickest way to access table entries. To fill a standard table, append lines using the
(APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX
option with the relevant ABAP command). The response time for accessing a standard table is in
linear relation to the number of table entries. If you need to use key access, standard tables are
appropriate if you can fill and process the table in separate steps. For example, you can fill a standard
table by appending records and then sort it. If you then use key access with the binary search option
(BINARY), the response time is in logarithmic relation to
the number of table entries.
Sorted Internal Tables
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard
tables, you can access them using either the table index or the key. When you use the key, the
response time is in logarithmic relationship to the number of table entries, since the system uses a
binary search. The key of a sorted table can be either unique, or non-unique, and you must specify
either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both
belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding
entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in
the table key. Table entries that do not fit are recognised before they are inserted. The response time
for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for
partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of
the table key.
Hashed Internal Tables
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key.
The response time is constant, regardless of the number of table entries, since the search uses a hash

Monday, January 30, 2017

L&T Infotech Proprietary

Page 1 of 7

algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table
definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You
cannot access hashed tables using the index. When you use key access, the response time remains
constant, regardless of the number of table entries. As with database tables, the key of a hashed table
is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
Index Tables
Index table is only used to specify the type of generic parameters in a FORM or FUNCTION. That
means that you can't create a table of type INDEX.
Internal tables are not DB tables. Standard and Sorted tables in combined are basically called as Index
tables and there nothing else. Here is the hierarchy
ANY TABLE
|
-----------------------------------|
|
Index Tables
Hashed Table
|
-----------------------------------|
|
Standard Table
Sorted Table

The ABAP Dictionary centrally describe and manages all the data definitions used in the system. The ABAP
Dictionary is completely in the ABAP Workbench. All the other components of the Workbench can actively
access the definitions stored the ABAP Dictionary. These objects can be automatically created in the
database with this definition.
The most important object types in the ABAP Dictionary are tables. Views, types (data elements,
structures, and tables types), domains, search helps and lock objects.
Purpose

Monday, January 30, 2017

L&T Infotech Proprietary

Page 2 of 7

Data definitions (metadata) are created and managed in the ABAP Dictionary. The ABAP Dictionary permits
a central description of all the data used in the system without redundancies. New or modified information
is automatically provided for all the system components. This ensures data integrity, data consistency and
data security.
Tables are defined in the ABAP Dictionary independently of the database. A table having the same
structure is then created from this table definition in the underlying database.
A table definition in the ABAP Dictionary contains the following components :

Table fields define the field names and data types of the fields contained in the table.

Foreign keys define the relationships between the tables.

Technical settings control how the table should be created in the database.

Table type

The table type determines how ABAP will access individual table entries. Internal
tables can be divided into three types:

Standard tables have an internal linear index. From a particular size upwards, the
indexes of internal tables are administered as trees. In this case, the index
administration overhead increases in logarithmic and not linear relation to the
number of lines. The system can access records either by using the table index or
the key. The response time for key access is proportional to the number of entries
in the table. The key of a standard table is always non-unique. You cannot specify
a unique key. This means that standard tables can always be filled very quickly,
since the system does not have to check whether there are already existing
entries.
Sorted tables are always saved sorted by the key. They also have an internal
index. The system can access records either by using the table index or the key.

Monday, January 30, 2017

L&T Infotech Proprietary

Page 3 of 7

The response time for key access is logarithmically proportional to the number of
table entries, since the system uses a binary search. The key of a sorted table can
be either unique or non-unique. When you define the table, you must specify
whether the key is to be unique or not. Standard tables and sorted tables are
known generically as index tables.
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.

Delivery Class
Use
You use the delivery class to control the transport of table data for an installation, upgrade, or client copy and
transports between customer systems. The delivery class is also used in the extended table maintenance.

Features
There are the following development classes:
A- Application table (master and transaction data).
C- Customer table, data is only maintained by the customer.
L- Table for storing temporary data.
1 G- Customer table, SAP can insert new data records but cannot overwrite or delete existing ones. The
customer namespace must be defined in table TRESC. To define the customer namespace use report
RDDKOR54. You can start it directly from the table maintenance by choosing Maintain Customer
Namespace on the Delivery and Maintenance tab.
E- System table with its own namespace for customer entries. The customer namespace must be defined in
table TRESC. To define the customer namespace use report RDDKOR54. You can start it directly from
the table maintenance by choosing Maintain Customer Namespace on the Delivery and Maintenance
tab.
S- System table, data changes have the status of program changes.
W- System table (for example table of the development environment) whose data is transported with its own
transport objects (such as R3TR PROG, R3TR TABL and so on).

Behavior During Client Copy

Only the data of client-dependent tables is copied.
Class C, G, E, S- The data records of the table are copied to the target client.
Class W, L- The data records of the table are not copied to the target client.

Monday, January 30, 2017

L&T Infotech Proprietary

Page 4 of 7

Class A- Data records are only copied to the target client if explicitly requested (parameter option). It is not
sensible to transport such data, but this is supported nevertheless to allow the entire client environment
to be copied.

Behavior During Installation, Upgrade and Language Import

The behavior of client-dependent tables differs from that of cross-client tables.
Client-Dependent Tables
1 Class A and C- Data is only imported into client 000. The system overwrites the existing data records.
Class E, S and W- Data is imported into all clients. The system overwrites the existing data records.
Class G- The system overwrites the existing data records in client 000. In all other clients, the system inserts
new data records, but existing data records are not overwritten.
Class L- No data is imported.
Cross-Client Tables
Classes A, L and C- No data is imported.
Classes E, S, and W- Data is imported. The system overwrites the existing data records with the same key.
Class G- The system inserts non-existent data records, but does not overwrite existing data records.

Behavior During Transport Between Customer Systems

Data records of tables having delivery class L are not imported into the target system. Data records of tables
having delivery classes A, C, E, G, S and W are imported into the target system (for client-dependent tables
this is done for the target clients specified in the transport).

Use of the Delivery Class in the Extended Table Maintenance

The delivery class is also used in the Extended Table Maintenance (transaction code SM30). The maintenance
interface generated for a table performs the following checks:
It is not possible to transport the entered data using the transport connection of the generated maintenance
interface for tables having delivery classes W and L.
Data that is entered is checked to see if it violates the namespace defined in table TRESC. If the data
violates the namespace, the system rejects the input

Use
You must define whether and how a table is buffered in the technical settings for the table. There are three
possibilities here:
Buffering not allowed:
Table buffering is not allowed. You use this option when, for example, application programs always need
the most recent data from the table or the table is changed too frequently.
Buffering allowed but switched off:
Buffering is allowed from the business and technical points of view. Applications which access the table
work correctly with and without table buffering. Whether or not table buffering results in a gain in
performance depends on the table size and access profile of the table (frequency of the different types
of table access). Initially the table buffering is not activated because it is not possible to know what these
values are in the customer system. If table buffering would be advantageous for the table size and
access profile of the table, you can activate it in the customer system at any time.
Buffering switched on:
The table is buffered. In this case you must specify a buffering type.

Monday, January 30, 2017

L&T Infotech Proprietary

Page 5 of 7

What is table maintenance generator?

Table Maintenance Generator is a tool used to customize the tables created by end users and can be changed as required, such
as making an entry to that table, deleting an entry etc.
In other words, table maintenance generator is a user interface tool which is used to change the entry of the table or delete an
entry from the table or create an entry for the table..
Transaction Codes
SE54: Generate Table Maintenance Dialog
SE55: Table view maintenance DDIC call
SE56: Table view display DDIC call
SE57: Deletion of Table Maintenance
SM30: Maintenance Table Views:
Authorization Group : If the table needs to be maintained by only particular group of people, then the Authorization group needs
to be filled otherwise fill it as NC. To maintain the authorization group refer to SU21.
Function group is the name to which the generated maintenance modules will belong to.
Generally Function Group name can be same as table name.
Maintenance screens: Maintenance can be done in 2 ways
1. Maintenance and Overview both on one screen
2. Maintenance on one screen and Overview on another screen.

Modifications Available in Table Maintenance

The Function Group created will be having the code and screens used in maintenance.
We can alter the way Maintenance data and screens are viewed by making the appropriate changes in the Function Group and its
screens.
Screen Alterations
Maintenance screen can be altered in a way that, if a field needs to be non-editable or default name appearing on the maintenance
screen for any field needs to be changed then following steps can be used to do the same
Go To Environment -> Modification -> Maintenance Screens

List of Events available in Table maintenance

01
Before saving the data in the database
02
After saving the data in the database
03
Before deleting the data displayed
04
After deleting the data displayed
05
Creating a new entry
06
After completely performing the function 'Get original'
07
Before correcting the contents of a selected field
08
After correcting the contents of a selected field
09
After getting the original of an entry
10
After creating the header entries for the change task (E071)
11
After changing a key entry for the change task (E071K)
12
After changing the key entries for the change task (E071K)

Monday, January 30, 2017

L&T Infotech Proprietary

Page 6 of 7

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
AA
AB
AC
AD
AE
AF
AG
AH
ST
AI

Exit editing (exit main function module)

After lock/unlock in the main function module
Before retrieving deleted entries
After retrieving deleted entries
Do not use. Before print: Event 26
After checking whether the data has changed
After initializing global variables, field symbols, etc.
after input in date sub screen (time-dep. tab. /views)
Fill hidden fields
Go to long text maintenance for other languages
Before calling address maintenance screen
After restricting an entry (time-dep. tab./views)
Individual authorization checks
Before creating a list
After creation or copying a GUID (not a key field)
After entering a date restriction for time-dep. views
Instead of the standard data read routine
Instead of the standard database change routine
Instead of the standard 'Get original' routine
Instead of the standard RO field read routine
Instead of standard positioning coding
Instead of reading texts in other languages
Instead of 'Get original' for texts in other languages
Instead of DB change for texts in other languages
GUI menu main program name
Internal use only

Monday, January 30, 2017

L&T Infotech Proprietary

Page 7 of 7