Ansicht
Dokumentation
ABENDDIC_DATABASE_TABLES_GTT - DDIC DATABASE TABLES GTT
Addresses (Business Address Services) BAL Application Log DocumentationThis documentation is copyright by SAP AG.
- Global Temporary Tables
Global temporary tables (GTTs) are special transparent tables intended for storing temporary data. This data exists only within a database LUW and can be accessed only by one consumer. GTTs are used to store temporary interim results to split 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 must 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 category global temporary table can be specified for a DDIC database table. Tables in this category are created as a GTT in the database. The following additional rules apply in access to GTTs in the ABAP Dictionary to avoid platform-dependent behavior and unexpected responses when handling GTTs:
- If an ABAP Dictionary GTT was filled by a modifying statement, it must be cleared explicitly before the end of the current database LUW. The following can be used here:
- The statement DELETE FROM dbtab without specifying a WHERE condition.
- All explicit database commits and database rollbacks, such as the statements COMMIT WORK, COMMIT CONNECTION, ROLLBACK WORK, ROLLBACK CONNECTION and all associated Native SQL statements and calls.
- If an ABAP Dictionary GTT filled using 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 obsolete addition CLIENT SPECIFIED is forbidden. This includes the use of CLIENT SPECIFIED in queries and the use of CLIENT SPECIFIED in UPDATE SET and DELETE FROM. The non-obsolete form of CLIENT SPECIFIED in write statements is allowed.
Besides these rules, GTTs can be used like regular transparent tables. Regarding their definition in ABAP Dictionary, the following settings are predefined and cannot be modified:
- The data type and size category are irrelevant and undefined.
- Table buffering is not allowed.
- Logging is disabled.
- The storage type is row store.
- The delivery class is L.
- No replacement objects can be defined.
The number of key fields of a GTT is limited to 15.
Notes
- When accessed using , 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 unit, 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.
- The statements COMMIT WORK and ROLLBACK WORK clear the GTTs of all currently open database connections, whereas COMMIT CONNECTION and ROLLBACK CONNECTION only delete the GTTs of the specified connection.
- 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 . 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 does not prevent the runtime error COMMIT_GTT_ERROR.
- INSERT statements with a subquery after FROM 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 AS ABAP.
- 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 , the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check.
ABAP Short Reference PERFORM Short Reference
This documentation is copyright by SAP AG.
Length: 9186 Date: 20240328 Time: 102829 sap01-206 ( 124 ms )