Global temporary tables (GTTs) are special transparent tables used as repositories for temporary data. This data exists only within a
database LUW and can be
accessed only by one consumer. GTTs are used to save temporary subtotals thereby splitting complicated
database processes into multiple steps. GTTs are designed for this purpose only and hence incur far lower administration costs than regular transparent tables.
The GTT concept specifies that a GTT is always empty at the start of a database LUW and hence always
has to be cleared at the end of each database LUW. Generally, database systems provide native support
for this concept by defining data in a GTT database table as transaction-specific data implicitly. This data is deleted automatically at the end of a database LUW (in a
database commit or database rollback).
In ABAP Dictionary, the table categoryglobal temporary table can be specified for a database table. Tables in this category have the variant GTT in the database. The following additional rules apply in
Open SQL access to GTTs in ABAP Dictionary to avoid platform-dependent behavior and unexpected responses when handling GTTs:
If an ABAP Dictionary GTT was filled by a modifying
Open SQL statement, it must be cleared explicitly before the end of the current
database LUW. The following can be used here:
If an ABAP Dictionary GTT filled using Open SQL was not cleared explicitly using one of these methods before an
implicit database commit, the runtime error COMMIT_GTT_ERROR occurs independently of its content.
The number of key fields of a GTT is limited to 15.
When accessed using Open SQL, explicit clears of ABAP Dictionary GTTs are forced before implicit database commits for the following reasons:
For making the program easier to understand. If an implicit database commit occurs within a programming module, for example due to an
RFC, a developer may be surprised
to find that the table is empty afterwards, since the database system deleted it implicitly at the end of the database LUW.
It prevents errors caused by any platform dependencies. It cannot be guaranteed that every database
platform deletes the data of a GTT in an implicit database commit. This is guaranteed, however, when the GTT is cleared explicitly.
Only the variant DELETE FROM dbtab
without a WHERE condition specified prevents the runtime error COMMIT_GTT_ERROR.
Other variants of the DELETE statement do not prevent the runtime error, even if they clear the entire table.
These additional rules apply only to writes using
Open SQL. If a GTT is filled using only
Native SQL or
AMDP methods, no exceptions are
raised in the case of implicit database commits. The GTT is then generally cleared by the database system.
Conversely, using Native SQL or AMDP to clear a table filled using Open SQL does not prevent the runtime error COMMIT_GTT_ERROR.
It is advisable to only use Open SQL to access ABAP Dictionary GTTs.
INSERT statements with a
subquery afterFROM are particularly well suited for filling GTTs, since the operation
is then performed only on the database and no data transports are required between the database and the application server.
If the data of a GTT is only required when accessing a database, it is possible to make the corresponding request using
common table expressions.
When an ABAP Dictionary GTT is accessed using Open SQL, the syntax check is performed in a
strict mode, which handles the statement more strictly than the regular syntax check.