These statements define an area in an ABAP program in which one or more
Native SQL statements can
be specified statically. The area between
is not checked completely by the syntax check. The statements entered there are passed to the Native SQL interface and processed there as follows:
Almost all SQL statements that are valid for the addressed database system can be included between
ENDEXEC, in particular the DDL statements. These SQL statements are passed from the Native SQL interface to the database system largely unchanged. The syntax rules are specified by the database system, in particular the case sensitivity rules for database objects. If the syntax allows a separator character between individual statements, multiple Native SQL statements can be included between
ENDEXEC. Generally, the semicolon (
;) is used as the separator character.
SAP-specific Native-SQL language elements can also be included between
ENDEXEC. These statements are not passed directly from the Native SQL interface to the database, but are converted appropriately. These SAP-specific language elements are:
All Native SQL statements bypass SAP buffering. Automatic client handling is not performed.
ENDEXEC sets the system fields
sy-dbcnt. When using the obsolete addition
PERFORMING, note that implicit cursor processing is carried out and the system fields are set for every read.
|The statements between
ENDEXEC were executed successfully.
|The statements between
ENDEXEC werenot successful. After implicit cursor processing with
sy-subrc always contains the value 4.
sy-dbcnt to the number
of table rows processed in the last Native SQL statement. After implicit cursor processing with
sy-dbcnt contains the total number of rows read. If an
overflow occurs because the number or rows is greater than 2,147,483,647,
sy-dbcnt is set to -1.
- Programs with Native SQL statements are generally dependent on the database system used, so that they cannot be executed in all AS ABAP systems. This is especially true for the examples in this section, which were written for Informix database systems, unless otherwise stated.
If insertions or modifications with Native SQL statements
INSERTor UPDATE would cause double rows with regard to the primary table key, no exception is raised. Instead,
sy-subrcis set to 4. However, if another operation, such as executing a Stored Procedure, would cause a double row, an exception would be raised.
- The client ID of a database table must be specified explicitly. Note that application programs should only use data from the current client. See also the associated security note and the programming guideline.
The obsolete addition
PERFORMING(not allowed in classes) executes implicit cursor processing and must no longer be used. The obsolete statement
EXIT FROM SQLcan be used to exit this type of processing.
Native SQL statements used for transaction control
ROLLBACK) are detected by the database interface and the actions required at the end of a transaction are performed.
The static embedding of Native SQL statements between
ENDEXECis replaced by dynamic passes to objects from ADBC classes. New features in the Native SQL in interface are now developed only in ADBC. Only ADBC should be used in new programs.
The following example demonstrates how a simple embedded Native SQL statement can be replaced by
ADBC. The use of the
NEW removes the need for a helper variable of type CL_SQL_STATEMENT when creating objects.
"Static Native SQL
"Dynamic Native SQL
NEW cl_sql_statement( )->execute_update( `COMMIT WORK` ).
See the executable example for static Native SQL.
Cause: Error when building up a secondary database connection.
Cause: Illegal interruption of a database selection. The cursor has been closed.
Cause: There is insufficient memory available for aNative SQL statement.
Cause: Database object already exists in the database. An attempt was made
to create a database object (for example, table, view, index) on the database, but this object already exists.
Cause: The name of a table or view that does not exist on the database was used.
Cause: An SQL error occurred while executing a native SQL command.
Cause: The maximum number of database connections (connections) has been exceeded.
Cause: The maximum number of pointers (cursors) has been exceeded.
Cause: The specified cursor does not exist. A
SELECTcommand in Native SQL has a specified cursor, but this cursor is unknown to cursor administration.
Cause: The specified cursor is already open. An
OPENcommand command in Native SQL has a specified cursor, which the cursor administration knows is already open.
Cause: There is insufficient roll memory available. When a Native SQL statement is processed, the internal memory is required to prepare the SQL Call.
Cause: An indicator variable has the wrong type. It must have the type INT2.
Cause: The connection name has already been assigned. A
CONNECTcommand in Native SQL has a specified connection name, which is already used for another connection.
Cause: The connection "DEFAULT" has been specified
DISCONNECTcommand in Native SQL. This connection cannot be terminated with
Cause: A Native SQL command contains too many variables. Here, variables
are all ABAP fields that are marked with a preceding colon(":"). If the
INTOclause has the form
INTO :wafor a work area
wa, then all the fields of
waalso count as variables.
DISCONNECTcommand in Native SQL has a specified connection that is unknown to the connection administration.
Cause: Despite the assertion
INTO STRUCTURE, the target option specified in the
INTO-clause is not structured.
Cause: A LOB Variable has the wrong type. LOB variables must have the type