Get Example source ABAP code based on a different SAP table
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. ITOC
Basic Rule ABAP-managed database objects are only intended only for use by ABAP programs in AS ABAP and for access using its database interface. The way in which instances of ABAP-managed database objects are managed 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) and there is no intermediate layer in the form of a Native SQL interface that could catch any changes. For example, it is not even possible to guarantee the names of the ABAP-managed database objects, such as ABAP_CDS_MNG_VIEWS , AMDP procedures, or AMDP functions. Accesses, such as using a ABAP_CDS_MNG_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.
Latest notes: 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. ABAP_HINT_END
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 AB_SQL as the primary method for accessing ABAP-managed database objects. AMDP should only be used when AB_SQL is not sufficient. And ABAP-managed Native SQL should itself only be used when AMDP is not sufficient. Non-ABAP managed Native SQL is not used to access database objects, as specified in the basic rule.
AB_SQL AB_SQL is the primary method for accessing ABAP-managed database objects. Only AB_SQL supports all functional and semantic properties of ABAP-managed database objects. Any internal changes made to ABAP-managed database objects are handled by the AB-SQL interface and are transparent for the ABAP program.
AMDP Unlike Native SQL, AMDP is a high-order wrapper of database-specific SQL. If the scope of AB_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 AB_SQL , but also to wrappers of SQL elements that do not yet exist in AB_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 as intended:
Calls of AMDP methods from ABAP or other AMDP methods.
Access to CDS table functions using ABAP CDS and AB_SQL .
If possible, no calls from Native SQL The use of AMDP lifts or weakens some Native SQL restrictions, but the functional and semantic properties of ABAP-managed database objects are not supported in the same way as in AB_SQL . Most of the following rules for Native SQL apply also to the implementation of AMDP methods, particularly to DML writes.
Latest notes: There is no benefit in moving SQL statements to AMDP methods, if they can also be formulated in AB_SQL . See the executable example. ABAP_HINT_END
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 the ABAP Dictionary is just as unknown as the semantic properties. 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 to the database, such as a CDS view with input parameters created as a SQL 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 depend on any other properties of the ABAP-managed database objects apart from 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-dependent 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 properties that are respected automatically in AB_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 AB_SQL .
In certain phases in system delivery or in upgrades, ABAP-managed database objects that allow writes can be replaced temporarily by database objects that do not allow 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 the ABAP Dictionary or AMDP. In the worst case, the direct use of DDL for ABAP-managed database objects can make AS ABAP unusable.
Latest 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 ABAP_CDS_MNG_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 or must not perform such an access.
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. ABAP_HINT_END
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 one or more applications can use AB_SQL , AMDP, or Native SQL to access the same database object. There is a risk here that mixing AB_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 AB_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 AB-SQL statements when using AMDP and Native SQL to access ABAP-managed data objects that can also be accessed by AB_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 AB-SQL statements behave differently than when changes are made using AB_SQL . In mixed access cases, all options in the implementation of AMDP methods or Native SQL should be exploited only to the extent that they do not endanger the consistency of an ABAP-managed data model. BEGIN_SECTION SAP_INTERNAL_HINT The respective SAP Note is 2511210. END_SECTION SAP_INTERNAL_HINT
