ABAP Keyword Documentation → ABAP − Reference → Processing External Data → ABAP Database Access
System Class for Database Features
The method USE_FEATURES of the class CL_ABAP_DBFEATURES can be used to detect whether the current database or a database specified using a database connection supports particular features and whether these can be used at runtime in ABAP. One or more features can be queried and then passed to the method in an internal table. The potential row content of the internal table is determined using constants of the class CL_ABAP_DBFEATURES. Other values raise an exception from the class CX_ABAP_INVALID_PARAM_VALUE.
| Constant | Database Feature | Use in ABAP |
|---|---|---|
| AMDP_TABLE_FUNCTION | Table Functions | Access to CDS table functions in ABAP SQL. |
| EXTERNAL_VIEWS | SAP HANA views | Access to external views in ABAP SQL. |
| CALL_AMDP_METHOD | Supports AMDP | Method call of AMDP procedure implementations. |
| CALL_DATABASE_PROCEDURE | Database Procedures | Call of database procedures using CALL DATABASE PROCEDURE. |
| CTE_IN_CORRELATED_SUBQUERIES | Common table expressions (CTE) | Access to common table expression in correlated subqueries. |
| HIERARCHIES | Hierarchy Data | Use of hierarchy data as a data source of queries in ABAP SQL |
| ITABS_IN_FROM_CLAUSE | Local temporary tables | Use of internal tables as adata source of queries in ABAP SQL, if these are evaluated by the database. |
| GROUPING_SETS | Grouping sets | Use of grouping sets in the GROUP BY clause in ABAP SQL |
| MODIFY_FROM_SELECT | Subquery in UPSERT | Use of a subquery as adata source of the statement MODIFY |
| LIMIT_IN_SUBSELECT_OR_CTE | Sorts or delimiters in subqueries | Use of the ORDER BYclause or the additions UP TO, OFFSET insubqueries. |
| TABLE_KEYCNT_MAX1 | Up to 120 key fields | A table can contain more key fields than is permitted as a cross-platform table. |
| TABLE_KEYLEN_MAX1 | Keys can have up to 2000 bytes | The key of a table can contain more bytes than is permitted as a cross-platform table. |
| TABLE_LEN_MAX1 | A table row can have up to 16293 bytes | A table row can contain more bytes than is permitted as a cross-platform table. |
| WINDOWING | Window expressions | Use of window expressions in a SELECT list in ABAP SQL. |
The method USE_FEATURES returns the value of abap_true if the feature is supported by the database and the specified use in ABAP is possible.
- Most of these features can be used statically in ABAP programs regardless of the current database system. This means there is no syntax error when one of these database features is used in an ABAP program. For example, it is possible to access external views in every ABAP program or AMDP methods can be called. An exception is raised only if the current database does not support the feature in question at runtime. A syntax warning from the extended program check (which can be hidden by a pragma) indicates the potential exception. The class CL_ABAP_DBFEATURES can be used to check whether a special form of access is possible at runtime, instead of catching the corresponding exception. Replacement implementations can be used if an access type is not possible.
- The features TABLE_KEYCNT_MAX1, TABLE_KEYLEN_MAX1, and TABLE_LEN_MAX1 can currently only be used by SAP developers as internal flags for database tables, which indicate the tables potentially exceed globally defined and cross-platform sizes. When a table like this is accessed using ABAP SQL, a syntax check warning from the extended program check is raised. This warning can be hidden by a pragma. The warning for TABLE_LEN_MAX1 is also raised for views that use a table of this type. In standard SAP systems, these tables are usually delivered within the general limits, but customers and partners can enhance them and exceed these sizes. Tables enhanced like this can only be accessed on database systems that support these expanded limits. Other database systems use a replacement implementation that can be accessed using the class CL_ABAP_DBFEATURES.
Other versions:
7.31 | 7.40 | 7.54
Notes
- If a syntax warning from the extended program check due to expanded database features is raised when a database object is accessed, it can be hidden by a pragma as long as the object was accessed on database systems that support the features or if there is a replacement implementation. If there is no guarantee that the object is accessed only on database systems that support the features in question, it is best to wrap the access behind an API.
- Tables flagged as potentially exceeding cross-platform sizes should never be accessed globally. They should always be accessed within an API wrapper and the associated replacement implementation should be wrapped too.
- As soon as all database systems support a database feature and it can be used in ABAP, the checks are no longer necessary. The associated constant is then disallowed and removed from the class CL_ABAP_DBFEATURES.
- The class CL_ABAP_DBFEATURES_AUNITHELPER can be used to reduce the set of database features in CL_ABAP_DBFEATURES during a unit test. In programs that use CL_ABAP_DBFEATURES, this makes it possible to test replacement implementations for databases that support fewer features than the current database.
Example
For the current database, checks whether specific additional features can be accessed using ABAP SQL.
IF cl_abap_dbfeatures=>use_features(
EXPORTING
requested_features =
VALUE #( ( cl_abap_dbfeatures=>amdp_table_function )
( cl_abap_dbfeatures=>external_views ) ) ).
...
ELSE.
...
ENDIF.
Example
The program DEMO_DBFEATURES checks all possible database features for the current database.