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.
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.
The features AMDP_TABLE_FUNCTION, EXTERNAL_VIEWS, CALL_AMDP_METHOD, and CALL_DATABASE_PROCEDURE
can be used statically in ABAP programs regardless of the current database system, which means that
no syntax errors are produced 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 (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 Open SQL, a syntax check warning occurs that can be hidden by a pragma. The warning for TABLE_LEN_MAX1 also occurs 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.
Notes
If a syntax warning due to expanded database features occurs when a database object is accessed,
it should only be hidden by a pragma if the object was accessed on database systems that support the
features or if there is a replacement implementation. It is a good idea to wrap accesses to these types of database objects in 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. This currently applies to the following constants:
VIEWS_WITH_PARAMETERS, CDS views with input parameters are supported by all database from Release 7.50.
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.
