1

Open SQL vs Native SQL

1. What is Open SQL vs Native SQL?

If you write a business application, there is always a database on backend. So SAP R/3
uses a database too. It is a
special database? No. SAP uses standard databases like Oracle, IBM DB2, MS SQL
Server, etc. If you have a database on backend, it is inevitable that you must use SQL.
SAP uses SQL to select, insert and update data inside database. However, the problem is
that if you use different databases, your code whatever it is whether ABAP or not, SQL
can vary. In that situation although programmers tend to use Standard SQL which is valid
for all databases, the problems sometimes occur to switch one database to different
database.

1.1 Open SQL

Open SQL consists of a set of ABAP statements that perform operation on central
database in the R/3 System. The results of the operations and any error messages are
independent of the database system in use. Open SQL thus provides a uniform syntax and
semantics for all of database systems supported by SAP. ABAP programs that only use
Open SQL statements will work in any SAP R/3 System, regardless of the database
system in use. Open SQL statements can work with database tables that have been
created in the ABAP Dictionary.

The method actually is simple that when a programmer writes an ABAP program with
Open SQL statements, the kernel SAP programs convert Open SQL statements to real /
native SQL statements for database in use. So like that write once, run for all databases
and even for all operating systems. Like Javas Write Once. Run Anywhere. Think
about Java, even the Java uses the same principal that is Java Virtual Machine which
looks like SAPs kernel programs. Right? Can we say SAP did Write Once. Run
Anywhere before Java?

Open SQL contains the following keywords:

SELECT - Reads data from database tables.

INSERT - Adds lines to database tables.
UPDATE - Changes the contents of lines of database tables.
MODIFY - Inserts lines into database tables or changes the contents of existing
lines.
DELETE - Delete lines from database tables.
OPEN CURSOR, FETCH, CLOSE CURSOR - Reads lines of database tables
using the cursor.

All Open SQL statements fill the following two system fields with return codes:
 2
Open SQL vs Native SQL

SY-SUBRC
After every Open SQL statement, the system field SY-SUBRC contains 0 if the
operation was successful, a value other than 0 if not.
SY-DBCNT
After an OPEN SQL statement, the system field SY-DBCNT contains the number
of database lines processed.

1.2 Native SQL

Native SQL is real SQL for database in use. It means beside OPEN SQL, if you need you
can use the native SQL for databases. Native SQL allows you to use database-specific
SQL statements in an ABAP program. This means that you can use database tables that
are not administered by the ABAP Dictionary, and therefore integrate data that is not part
of the R/3 System.

As a rule, an ABAP program containing database-specific SQL statements will not run
under different database systems. If your program will be used on more than one database
platform, only use Open SQL statements.

All ABAP programs in SAP R/3 System have been written with Open SQL. I think if
you have a different database instant in the same database, you can use Native SQL
statement to connect and do operation on this database instant.

Lets assume you have an SAP R/3 system that uses Oracle database instant ORC1. You
have another application, even it uses the same database Oracle, but as normally different
database instant ORC2. So like data inside ABAP program, you can use Native SQL
statements to connect ORC2, non-SAP database instant, to integrate SAP R/3 and non-
SAP system. It is kind of an integration activity.

If you create a table by using database tools, without ABAP Dictionary, you are not able
to use Open SQL to reach this table. You just can use Native SQL to do that.

Native SQL statements bypass the R/3 database interface. There is no table logging, and
no synchronization with the database buffer on the application server. For this reason, you
should, wherever possible, use Open SQL to change database tables declared in the
ABAP Dictionary. In particular, tables declared in the ABAP Dictionary that contain log
columns with types LCHR and LRAW should only be addressed using Open SQL, since
the columns contain extra, database-specific length information for the column. Native
SQL does not take this information into account, and may therefore produce incorrect
results. Furthermore, Native SQL does not support automatic client handling. Instead,
you must treat client fields like any other.

To ensure that transactions in the R/3 System are consistent, you should not use any
transaction control statements (COMMIT, ROLLBACK WORK), or any statements that
set transaction parameters (isolation level) using Native SQL.
 3
Open SQL vs Native SQL

Using Native SQL, you can

Transfer values from ABAP fields to the database

Read data from the database and process it in ABAP programs.

Native SQL works without the administrative data about database tables stored in the
ABAP Dictionary. Consequently, it cannot perform all of the consistency check used in
Open SQL. This places a larger degree responsibility on application developers to work
with ABAP fields of the correct type. You should always ensure that the ABAP data type
and the type of database column are identical.

2. What does an EXEC SQL statement do in ABAP?

EXEC SQL
Syntax
EXEC SQL [PERFORMING subr].
...
ENDEXEC.
Effect

These statements define an area in an ABAP program in which one or more

Native SQL statements are to be carried out. The area between EXEC and
ENDEXEC is not completely checked 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 EXEC and 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, you can
include several Native SQL statements between EXEC and ENDEXEC.
Generally, the semicolon (;) is used as the separator character.
You can also include SAP-specific Native SQL language elements
between EXEC and 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::

Host variables
Statements for cursor processing
Database procedure calls
Statements for establishing database connections
 4
Open SQL vs Native SQL

All Native SQL statements bypass SAP buffering. Automatic client handling is not
performed.

System fields

The statement ENDEXEC sets the system fields sy-subrc and sy-dbcnt. When
using the addition PERFORMING, note that implicit cursor processing is carried out
and the system fields are set for every read process.

sy-
subrc Meaning

0 The statements between EXEC and ENDEXEC were executed successfully.

The statements between EXEC and ENDEXEC were not executed. After implicit
4
cursor processing with PERFORMING, sy-subrc always contains the value 4.

The ENDEXEC statement sets sy-dbcnt to the number of table rows processed
in the last Native SQL statement. After implicit cursor processing with
PERFORMING, sy-dbcnt contains the total number of lines read.

Note

Programs with Native SQL statements are generally dependent on the database
system used, so that they cannot be executed in all ABAP systems. This is
especially true for the examples in this section, which was written for Informix
database systems.

3. What is the disadvantage of using it?

Native SQL Advantages and Disadvantages - EXEC SQL statement

Advantages

Tables are not declared in ABAP Dictionary can be accessed. (e.g. Tables
belonging to sys or system user of Oracle, etc.)
To use some of the special features supported by the database-specific SQL. (e.g.
Passing hints to Oracle optimizer.)

Disadvantages

No syntax check is performed whatever is written between EXEC and

ENDEXEC.
 5
Open SQL vs Native SQL

ABAP program containing database-specific SQL statements will not run under
different database systems.
There is no automatic client handling for client dependent tables.
Care has to be taken during migration to higher versions.

Example 1

Inserting two rows in the database table SCARR. If neither of these rows exists, sy-subrc
is set to 0 by ENDEXEC and sy-dbcnt to 1. Otherwise, an exception is raised and
handled.

DATA: exc_ref TYPE REF TO cx_sy_native_sql_error,

error_text TYPE string.

TRY.
EXEC SQL.
INSERT INTO scarr
(MANDT, CARRID, CARRNAME, CURRCODE, URL)
VALUES ('000', 'FF', 'Funny Flyers', 'EUR', 'http://www.ff.com');
INSERT INTO scarr
(MANDT, CARRID, CARRNAME, CURRCODE, URL)
VALUES ('000', 'EF', 'Easy Flyers', 'EUR', 'http://www.ef.com');
ENDEXEC.
CATCH cx_sy_native_sql_error INTO exc_ref.
error_text = exc_ref->get_text( ).
MESSAGE error_text TYPE 'I'.
ENDTRY.

Example 2

Reading several rows from the database table SPFLI using cursor handling and host
variables in native SQL. If rows were found, sy-subrc is set to 0 and sy-dbcnt is
increased by one for each row read.

PARAMETERS p_carrid TYPE spfli-carrid.

DATA: connid TYPE spfli-connid,

cityfrom TYPE spfli-cityfrom,
cityto TYPE spfli-cityto.

EXEC SQL.
OPEN dbcur FOR
SELECT connid, cityfrom, cityto
FROM spfli
WHERE carrid = :p_carrid
 6
Open SQL vs Native SQL

ENDEXEC.

DO.
EXEC SQL.
FETCH NEXT dbcur INTO :connid, :cityfrom, :cityto
ENDEXEC.
write: / connid,cityfrom,cityto.
IF sy-subrc <> 0.
EXIT.
ELSE.
...
ENDIF.
ENDDO.

EXEC SQL.
CLOSE dbcur
ENDEXEC.