SAP DDIC DATABASE TABLES GTT



Get Example source ABAP code based on a different SAP table
  



ABAP_DDIC - Global Temporary Tables
Global temporary tables (GTTs) are a special kind of transparent tables intended for storing temporary data. This data exists only within a database LUW and can be accessed only by a 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. Most database systems provide native support for this concept by implicitly defining data in a GTT database table as transaction-specific data. This data is deleted automatically at the end of a database LUW, that means, during 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 AB_SQL access to GTTs to avoid platform-dependent behavior and unexpected responses when handling GTTs:
If an ABAP Dictionary GTT was filled by a modifying AB-SQL statement, it must be cleared explicitly before the end of the current database LUW. The following can be used here:
The AB-SQL statement DELETE FROM dbtab without specifying a WHERE condition.
All explicit database commits and database rollbacks, such as the AB-SQL statements COMMIT WORK, COMMIT CONNECTION, ROLLBACK WORK, ROLLBACK CONNECTION
BEGIN_SECTION VERSION 5 OUT and all associated Native SQL statements and calls.
END_SECTION VERSION 5 OUT
If an ABAP Dictionary GTT filled using AB_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.
BEGIN_SECTION VERSION 5 OUT
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.
END_SECTION VERSION 5 OUT
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.



Latest notes:
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.
It is advisable to only use AB_SQL to access ABAP Dictionary GTTs.
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 for the time span of a database access, common table expressions might be an alternative option.
When accessed using AB_SQL , explicit clears of ABAP Dictionary GTTs are enforced before implicit database commits for the following reasons:
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.
NON_V5_HINTS
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.
These additional rules apply only to writes using AB_SQL . If a GTT is filled using only AMDP or Native SQL 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 AB_SQL does not prevent the runtime error COMMIT_GTT_ERROR .
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.
When an ABAP Dictionary GTT is accessed using AB_SQL , the syntax check is performed in ABAP_STRICT_762 strict mode / , which handles the statement more strictly than the regular syntax check.
ABAP_HINT_END

ABAP_EXAMPLES_ABEXA
Global Temporary Tables, Access
Union with Global Temporary Table
ABAP_EXAMPLE_END