This blog summarizes some facts and rules regarding database objects managed by the
AS ABAP. That should have been done long before. But recently it became more and more important, because there is an increasing tendency to access ABAP-managed database objects directly from native HANA objects while - on the other hand - the ABAP-managed database objects become more and more complex. This might lead to one or the other unpleasant surprise. For an official statement, see also
SAP Note 2511210.
Database Objects
A database object is an artefact such as a database table, an SQL view, or a stored procedure. As a rule, a database object is defined with the database's
DDL, e.g. with
CREATE VIEW. We do not talk about HANA's calculation views here.
ABAP-Managed Database Objects
An ABAP-managed database object is a database object in the
ABAP database schema in the standard database of an
AS ABAP, that is both managed and used by the AS ABAP. The AS ABAP offers tools and frameworks as
ABAP Dictionary,
ABAP CDS, and
AMDP to create and edit such database objects. The objects are not maintained directly in the development environment of the database platform. The respective DDL is generated by the database interface of the AS ABAP.
The most important ABAP-managed database objects are:
Besides the database objects themselves, the definitions of these objects in the AS ABAP frameworks cover further attributes described by metadata that are not known on the database, e.g. ABAP types, client dependency, table buffering, foreign key relations and so on. Those are evaluated by the AS ABAP itself.
Accessing ABAP-Managed Database Objects
ABAP-Managed Database Objects can be accessed as follows:
- Via the database interface of AS ABAP
- Via interfaces other than the database interface of AS ABAP
- We call such an access Non-ABAP-Managed Native SQL
- This SQL is executed in the database without being checked in AS ABAP
The main properties of these accesses can be summarized as follows:
Rules for Accessing ABAP-Managed Database Objects
Basic Rule
ABAP-managed database objects are only to be used by ABAP programs in AS ABAP and must be accessed through its database interface only. This means: No access using non-ABAP managed Native SQL!
The way in which instances of ABAP-managed database objects are created is an internal affair of the AS ABAP. The actual implementation can change in incompatible ways when the release is upgraded. When using non-ABAP managed Native SQL to access objects, the same restrictions apply as when using ABAP-managed Native SQL (see below). Moreover, there is no Native SQL interface that can act as a layer to catch any changes. For example, it is not even possible to guarantee the names of the ABAP-managed database objects, such as CDS database views, AMDP procedures, or AMDP functions. Accesses such as using a CDS database view as a data source of a SAP HANA view or calling an AMDP function in a non-ABAP managed database procedure can become invalid at any time. Furthermore, the ABAP-specific session variables in the SAP HANA database, which can modify the way ABAP-managed database objects work, are not set and where-used lists using ABAP methods are not possible.
In exceptional cases, applications can bypass this basic rule if they can accept the lack of technical support provided by the AS ABAP infrastructure when ABAP-managed database objects are accessed from outside AS ABAP and errors occur as a result. Applications are themselves responsible for avoiding errors like this and removing any errors that do occur.
Rules for Valid Use
Within the database, ABAP-managed database objects should only be accessed from other ABAP-managed database objects. ABAP programs should use Open SQL as the primary method for accessing ABAP-managed database objects. AMDP should only be used when Open SQL is not sufficient. And ABAP-managed Native SQL should itself only be used when AMDP is not sufficicient. Non-ABAP managed Native SQL should not be used at all to access ABAP-managed database objects, as specified in the basic rule.
Open SQL
Open SQL is the primary method for accessing ABAP-managed database objects. Only Open SQL supports all functional and semantic attributes of ABAP-managed database objects. Any internal changes made to ABAP-managed database objects are handled by the Open SQL interface and are transparent for the ABAP program.
AMDP
In comparison with Native SQL,
AMDP provides a high-order wrapper of database-specific SQL. If the scope of Open SQL is not sufficient, the first option is to try AMDP for access to ABAP-managed database objects. This mainly applies to database procedure calls not supported in Open SQL, but also to wrappers of SQL elements that do not yet exist in Open SQL and which do not have an adequate alternative. Examples are the use of built-in functions that are not yet supported in Open SQL.
In principle, AMDP should only be used in accordance with its design:
- Calls of AMDP methods from ABAP or other AMDP methods.
- Access to CDS table functions using ABAP CDS and Open SQL.
- If possible, no calls from Native SQL
The use of AMDP lifts or weakens some Native SQL restrictions, but it does not provide the same support for functional and semantic attributes of ABAP-managed database objects as Open SQL.
Most of the following rules for Native SQL apply also to the implementation of AMDP methods, particularly regarding DML writes.
ABAP-Managed Native SQL
ABAP-managed
Native SQL (
ADBC,
EXEC SQL) is subject to most of the same restrictions as non-ABAP-managed Native SQL. The field order defined in ABAP Dictionary is just as unknown as the semantic attributes. Mappings between ABAP types and database types are only possible for certain types. There is no automatic client handling and the table buffer is always bypassed. The current instances of CDS entities must be known on the database, such as a CDS view with input parameters can be created as a database view or database function. Incompatible changes are also a possibility. CDS access control is bypassed.
Access to objects using the Native SQL interface offers some benefits over non-ABAP-managed Native SQL, such as the availability of environment information in session variables (on HANA only) Despite this, ABAP-managed Native SQL should only be used if AMDP methods are not sufficient. The following rules should be followed in this case:
- Only DML read statements should be used.
- These read statements should not be dependent on any other attributes of the ABAP-managed database objects, with the exception of their names and the names of components. It should be noted here that, when database objects of CDS entities are accessed, even the name cannot be guaranteed
- Mappings between ABAP types and database types are only possible for certain types. In all other cases, unexpected results or errors can occur. This applies in particular to platform-specific truncating or padding of values.
- The field order is undefined and is not stable. SELECT *, for example, should not be used to access objects.
- It is probable that an ABAP-managed database object is replaced by a different type of database object, such as a database table by a view.
- If necessary, the ABAP-specific attributes that are respected automatically in Open SQL, such as client handling or special type conversions, must be programmed explicitly when using Native SQL.
- DML write statements, such as INSERT, UPDATE or, DELETE can cause problems and should be avoided. Alongside the points for reads above, the following should be noted:
- There are no ABAP-specific type conversions and null values are not avoided, which can cause data inconsistencies and problems when accessing objects in ABAP programs.
- Native SQL writes are not registered by buffer synchronization in the table buffer, which means they are not detected in Open SQL.
- In certain phases in system delivery or in upgrades, ABAP-managed database objects that permit writes can be replaced temporarily by database objects that reject writes. Hence, these objects would produce errors when accessed.
- ABAP-managed database objects should never be accessed using DDL. It is technically possible to use DDL, however changes to the definition of ABAP-managed database objects are the sole responsibility of frameworks such as ABAP Dictionary or AMDP. In the worst case, the direct use of DDL for ABAP-managed database objects can make an AS ABAP unusable.
Applications that use ABAP-managed Native SQL are responsible for any aspects not supported by the Native SQL interface. One example is when a CDS database view is accessed whose DDL source code uses the CDS session variable
client. This is represented in the database object by the HANA session variable CDS_CLIENT, which is not set by the Native SQL interface The application itself must provide the required value, otherwise it cannot access the object in question.
Mixed Access
The various types of access to ABAP-managed database objects can also occur in mixed forms. This means that it is possible to use Open SQL, AMDP, or Native SQL to access one and the same database object. There is a risk here that mixing Open SQL with AMDP and Native SQL to access objects can produce errors, if you expect that Native SQL shows ABAP-specific behavior that is only guaranteed when using Open SQL.
Examples:
- Different conversion rules when mapping non-matching types
- Different handling of null values
- Differently set environment information
For this reason, care should be taken to preserve the semantics of the Open SQL statements when using AMDP and Native SQL to access ABAP-managed data objects that can also be accessed by Open SQL.
- When data is read using AMDP or Native SQL, the type conversions for non-matching types must be respected and the values may need to be modified to make them ABAP-specific.
- When data is written using AMDP and Native SQL, it must not be modified in ways that make subsequent Open SQL statements behave differently than when changes are made using Open SQL.
In mixed access cases, in the implementation of AMDP methods or in Native SQL not all possible options should be exploited in order to protect the consistency of an ABAP-managed data model.
