Get Example source ABAP code based on a different SAP table
ABAP_BACKGROUND In ABAP, data in database tables can be accessed in the following ways:
Open SQL>> Implemented by ABAP statements, this is a subset of the Structured Query Language (SQL>) comprising the DML> (Data Manipulation Language) part. The statements of Open SQL> use the Open SQL > interface to access, independently of the platform, the database tables of the database of an AS ABAP> that are defined in the ABAP Dictionary.
Native SQL>> Database-specific SQL> statements that include both DML> and DDL> (Data Definition Language) statements and which can be passed to the Native SQL> interface of the database as follows:
The methods of ADBC>> make it possible to execute dynamic SQL> statements on a database system and process the results. ADBC> (ABAP Database Connectivity>), a class-based API> that enables object-oriented access to the Native SQL> interface.
Native SQL> statements can be specified in ABAP programs between the statements EXEC SQL>> and ENDEXEC >>. Static Native SQL> statements of this kind are not checked completely by the syntax check and are forwarded almost unchanged from the Native SQL> interface to the database of an AS ABAP>. All access types enable access, not only to the central database of an AS ABAP> (standard connection), but also to other databases, using additional connections.
ABAP_RULE Using Open SQL>> Use Open SQL> for general persistence services where possible. Only use Native SQL> for tasks where Open SQL> is not suitable.
ABAP_DETAILS Only Open SQL> is guaranteed to be independent of the database platform used. For this reason, Open SQL> does not contain the set of all possible SQL> statements in a specific database, but only a subset of the DML> scope of all database systems supported by AS ABAP>. The database tables that can be processed using Open SQL > can be used in ABAP directly as structured types for the declaration of suitable work areas. Only Open SQL> supports SAP buffering of table content in the shared memory>. Native SQL> should only be used if the task really cannot be solved using Open SQL>. Services that work with Native SQL> are generally dependent on the database system used, so that they cannot be executed in all AS ABAP> systems. For platform-independent services, implementations should be provided for all supported databases. If the database is to be accessed using the Native SQL> interface instead if the Open SQL> interface, ADBC >> should be used. ADBC> is a modern object-oriented API > that is better suited to modern ABAP programming than EXEC SQL>>. Enhancements to the Native SQL> interface, such as bulk access using internal tables, are now only provided using ADBC>. ADBC> also enables dynamic access>; Native SQL > on the other hand is just static.