ABAP Keyword Documentation →  ABAP − Reference →  Processing External Data →  ABAP Database Access →  ABAP-Managed Database Objects 

Rules for Accessing ABAP-Managed Database Objects

The preceding sections

• show an overview of ABAP-managed database objects

• summarize how ABAP-managed database objects are accessed.

The following rules for accessing ABAP-managed database objects are based on these two points.

• Basic Rule

• Rules for Valid Use

• ABAP SQL

• AMDP

• ABAP-Managed Native SQL

• Mixed Access

Other versions: 7.31 | 7.40 | 7.54

Basic Rule

ABAP-managed database objects are only to be used by ABAP programs in AS ABAP and for access through its database interface.

The way in which instances of ABAP-managed database objects are created is the sole responsibility of 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. Access methods 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. If data aging is to be respected, this has to be programmed.

Note

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:

• Applications delivered by SAP must be secured reliably against errors. If necessary, the prerequisites for accessing ABAP-managed database objects from outside AS ABAP must be described in SAP Notes.

• Partners and customers should only access ABAP-managed database objects from outside AS ABAP when this is allowed by SAP and when the associated prerequisites are known and can be met.

Rules for Valid Use

Within the database, ABAP-managed database objects can only be accessed from other ABAP-managed database objects. ABAP programs should use ABAP SQL as the primary method for accessing ABAP-managed database objects. AMDP should only be used when ABAP SQL is not enough. And ABAP-managed Native SQL should itself only be used when AMDP is not enough. Non-ABAP managed Native SQL is not used to access database objects, as specified in the basic rule.

ABAP SQL

ABAP SQL is the primary method for accessing ABAP-managed database objects. Only ABAP 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 ABAP 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 ABAP 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 ABAP SQL, but also to wrappers of SQL elements that do not yet exist in ABAP SQL and which do not have an adequate alternative, such as the use of non-supported built-in functions.

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 ABAP SQL.

• If possible, no calls from Native SQL

The use of AMDP lifts or weakens some Native SQL restrictions, but it still far from provides the same support for functional and semantic attributes of ABAP-managed database objects as in ABAP SQL.

Most of the following rules for Native SQL apply also to the implementation of AMDP methods, particularly to DML writes.

Note

There is no benefit in moving SQL statements to AMDP methods, if they can be formulated in ABAP SQL. See the executable example.

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 impossible to know as the semantic attributes. Mappings between ABAP types and database types are only possible for certain types. There is no implicit 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 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 and non-modifiable) or the fact that data aging is respected. Despite this, this method 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 ABAP 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 ABAP 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 databases 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 AS ABAP unusable.

Notes

• As is the case when using non-ABAP managed Native SQL, 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.

• It might be possible to handle any future incompatible changes made to ABAP-managed database objects using the Native SQL interface, but this cannot be guaranteed.

Mixed Access

The various types of access to ABAP-managed database objects can also occur in mixed forms (from a technical perspective). This means that, for one or more applications, it is possible to use ABAP SQL, AMDP, or Native SQL to access one and the same database object. There is a risk here that mixing ABAP SQL with AMDP and Native SQL to access objects can produce errors, since Native SQL expects ABAP-specific behavior that is only guaranteed when using ABAP 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 ABAP SQL statements when using AMDP and Native SQL to access ABAP-managed data objects that can also be accessed by ABAP 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 ABAP SQL statements behave differently than when changes are made using ABAP SQL.

In mixed access cases, all options in the implementation of AMDP methods or Native SQL should be exploited only as far as they do not endanger the consistency of an ABAP-managed data model.