ABAP Keyword Documentation → ABAP − Reference → Processing External Data → ABAP Database Access → ABAP-Managed Database Objects → Access to ABAP-Managed Database Objects
Native SQL Access to ABAP-Managed Database Objects
Two methods of Native SQL access to ABAP-managed database objects can be distinguished.
Other versions:
7.31 | 7.40 | 7.54
Access Using ABAP-Managed Native SQL
ABAP-managed Native SQL is the variant of Native SQL used by ABAP programs to access the database through the Native SQL interface in AS ABAP. It encompasses the following:
The Native SQL interface passes vendor-specific SQL statements to the database system without making any modifications. Alongside this, SAP-specific Native SQL is available, which is processed in platform-dependent parts of the interface (Client Libraries).
Native SQL can be used to access ABAP-managed database objects as follows:
- Reads and writes on the following ABAP-managed database objects using database-specific SQL:
- Instances of the database tables and classic database views defined in ABAP Dictionary.
- Instances of the CDS database views of CDS views defined in ABAP CDS.
- Calls of the following ABAP-managed database procedures or database functions:
- It is possible to call AMDP procedures and AMDP functions that do not implement any CDS table functions.
- The AMDP table function of a CDS table function can be called.
- The ABAP-specific session variables can be accessed on the SAP HANA database using the built-in HANA function SESSION_CONTEXT.
The most important features of Native SQL are as follows:
- Native SQL is platform-dependent.
- Data types defined in ABAP Dictionary (and any enhancements of these types) are not currently known in Native SQL.
- Native SQL does not respect the order of fields defined in ABAP Dictionary, which can differ from the order in the database.
- The platform-dependent parts (Client Libraries) of the Native SQL interface support mappings between ABAP types and appropriate database types for bound parameters in ADBC and host variables after EXEC SQL. If types are not appropriate, on the other hand, platform-dependent conversions are made, which can easily produce unexpected results and errors.
- Any null values passed to ABAP data objects using the Native SQL interface are transformed to their type-dependent initial values. In the case of writes, null values can be created.
- When procedures are called, Native SQL provides the following special methods alongside the platform-specific SQL statements:
- The method EXECUTE_PROCEDURE of the class CL_SQL_STATEMENT
- The statement
EXECUTE PROCEDURE
afterEXEC SQL
- Bindings of internal ABAP tables to Native SQL are only possible using the methods SET_PARAM_TABLE of the classes
CL_SQL_STATEMENT and
CL_SQL_RESULT_SET in ADBC. Internal tables cannot be used as
host variables after
EXEC SQL
and cannot be used as parameters of the method EXECUTE_PROCEDURE in ADBC.
- When AMDP procedures and AMDP functions are called, it cannot be guaranteed that that the database objects exist or that their content is up-to-date. This is only the case in calls from ABAP and when accessing objects using ABAP SQL. Before an object is accessed using Native SQL, methods of the documented class CL_AMDP_RUNTIME_SERVICES can be used to created the database objects. This applies both to direct calls and to indirect cases, such as when CDS database views are accessed in whose DDL source code CDS table functions are used as a data source.
- Native SQL does not support the following ABAP Dictionary and ABAP CDS functions:
- Native SQL does not support implicit client
handling. The client ID must always be specified explicitly. To enable this, a parameter must be
bound in ADBC or a host variable used after
EXEC SQL
. The ABAP-specific session variables CLIENT and CDS_CLIENT can be accessed on the SAP HANA database. It must be noted here that, when using Native SQL, the value of the session variable CDS_CLIENT cannot be set to a different value using ABAP methods.
- Native SQL does not support table buffering.
- Native SQL does not support CDS access control.
- Native SQL cannot handle the enhancement category of structures.
- Native SQL does not support the logging of database tables.
- Native SQL accesses the database objects of CDS entities directly and ignores any other properties of CDS entities:
- When the CDS database view of a CDS view is accessed, the database-specific instance created of this view must be known. This applies in particular to CDS views with input parameters.
- When an instance of a CDS table function is accessed, its AMDP table function must be called.
- Native SQL cannot handle CDS associations and CDS roles.
- Care must be taken that all session variables used in a CDS view have the correct value. This applies in particular to the session variable client, which is mapped to the HANA session variable CDS_CLIENT and not to CLIENT.
- The ABAP-managed database objects accessed in Native SQL are not recorded in a where-used list. Where-used lists can only be created indirectly, by declaring suitable parameters and host variables in references to the dictionary types of the database objects. Another option is a full text search in the ABAP source code in AS ABAP.
- DDL statements are allowed in Native SQL.
- Native SQL supports ABAP-managed secondary connections and service connections.
- Native SQL respects the dependency rules defined for a database.
- Native SQL respects data aging by default.
- When ADBC is used, Native SQL is either fully dynamic or, if
EXEC SQL
is used, fully static.
Access Using Non-ABAP-Managed Native SQL
Non-ABAP-managed Native SQL consists of SQL statements that are passed to the database using interfaces other than the Native SQL interface of AS ABAP or that are executed in the database without being checked in AS ABAP. Examples are database objects in the SAP HANA database created by SAP Web IDE for SAP HANA that access ABAP-managed database objects, views that access database tables in ABAP Dictionary, or database procedures that call AMDP procedures or functions.
In general, the same applies to access using non-ABAP-managed Native SQL as to accessing ABAP-managed Native SQL. There are, however, the following additional restrictions:
- The precise instance of an ABAP-managed database object that is created and its name are undefined and can change between releases. Only the AS ABAP database interface can react to changes of this type and make them transparent to the consumer.
- The implementation of a database object managed by ABAP and the way it functions can be dependent on ABAP-specific context information that is provided only in cases where the database is a standard AS ABAP database and addressed using its database interface. More specifically, the content of the ABAP-specific session variables in the SAP HANA database can be set correctly only when an object is accessed from ABAP. On other database platforms, in fact, only CDS session variables are set when CDS entities are accessed using ABAP SQL.
- Only in cases where access is made from AS ABAP can it be guaranteed that an ABAP-managed database object actually exists and its content is up-to-date. The time when the instance is created or updated is not fixed and the existence or consistency of the instance is not guaranteed for access from sources other than AS ABAP. This applies in particular to AMDP procedures and AMDP functions whose existence and consistency is only guaranteed by the AMDP framework of AS ABAP.
- A where-used list for ABAP-managed database objects does not have any way of detecting when an object is used by non-ABAP-managed Native SQL.
- Non-ABAP-managed Native SQL does not support any ABAP-managed secondary connections and service connections.
- Non-ABAP-managed Native SQL does not respect data aging. If there is no suitable dependency rule, all partitions in the main memory of the SAP HANA database must be read.
Note
A dependency rule defined for a database table is also respected by non-ABAP-managed Native SQL, since this rule is evaluated by the optimizer of the SAP HANA database.