ABAP Keyword Documentation → ABAP − Reference → Processing External Data → ABAP Database Access
Native SQL
The term Native SQL refers to all statements and calls that can be passed to the Native SQL interface of the database interface. By default, the standard connection is used to access the ABAP database schema of the standard AS ABAP database.
Native SQL can be passed to the database interface as follows:
- In strings passed to objects in the ADBC classes.
- As statically embedded Native SQL statements.
ADBC is recommended. New developments and improvements, such as support for new SQL statements or optimized
performance using bulk access across internal tables, are now made only for ADBC. The existing static
embedding of Native SQL statements between EXEC
SQL and ENDEXEC
is still supported but should no longer be used in new programs.
Other versions:
7.31 | 7.40 | 7.54
Notes
- When using Native SQL, the order of the columns in database tables defined in ABAP Dictionary in the database system does not match the order of the structure definition in ABAP Dictionary. When using ABAP SQL, this is handled accordingly in the database interface and the order in ABAP Dictionary always applies. When using Native SQL, the order of the columns in the database system must be applied explicitly.
- Special care must be taken when using Native SQL to pass data from ABAP to the database system and
back. This applies both when using ABAP data objects as host variables or bound parameters in Native
SQL statements and when binding ABAP data object to the parameter interface of stored procedures or
database procedures. Not all built-in ABAP types have matching types in the type system of the database
system. Although types from the ABAP Dictionary can be mapped to ABAP types and the appropriate conversions can be executed from the ABAP SQL interface when using ABAP SQL, when using Native SQL only matching data types should be
mapped and conversions should be avoided.
This is particularly relevant for the ABAP types
n
,d
, andt
and decimal floating point numbers.
- Native SQL does not support implicit client handling. When accessing client-specific database tables or views, the required client ID must be selected explicitly. In application programs, only the current client should be used to do this.
- Table buffering is bypassed when using Native SQL.
- When the CDS database view of a client-specific CDS view is accessed using Native SQL and the client handling of the view is specified by the annotation @ClientHandling.algorithm:#SESSION_VARIABLE, the session variable $session.client is generally evaluated here. Only on SAP HANA databases, is an instance of this session variables created as a HANA session variable CDS_CLIENT. Its current value is used here. On other platforms, there can be unexpected behavior or the program may crash.
- Alongside their differences in syntax, Native SQL statements can behave in different ways on different platforms (particularly when compared with ABAP SQL). This mainly affects the following:
- Handling of blanks in strings
- Calculation rules and roundings in arithmetic calculations
- Overflow behavior
- Special care should be taken when using the Native SQL statements SET TRANSACTION to set the transaction behavior of the current database connection. The default behavior must be reset at the end of the current database LUW to avoid unwanted or critical behavior. When the SAP HANA database is accessed, special methods must be used that reset automatically instead of these Native SQL statements.
- The examples shown for Native SQL generally work in SAP's own SAP HANA database. The documentation about Native SQL in the SAP HANA database can be found under SAP HANA SQL and System Views References.
Programming Guideline
Continue
ADBC - ABAP Database Connectivity