Native SQL is very important as it allows you to execute nearly
all available statements through the SQL programming interface (usually known
as SQL Call Interface or similar) for directly executing SQL program code
(using EXEC IMMEDIATE or a similar command). The statements that are not
supported are listed in the following section:
·
Native SQL and the Database Interface,
·
Native SQL and Transactions
·
Native SQL and the Database Interface
Native SQL statements bypass the R/3 database interface.
With the database buffer on the application server, there is no table logging,
and no synchronization. Therefore, you should use Open SQL to change database
tables declare in the ABAP dictionary wherever possible. Since the columns
contain extra database specific length information for the column tables
declared in the ABAP dictionary, containing long columns with the type LCHAR or
LRAW should only be addressed using Open SQL. Native SQL may not produce the
correct result, as it does not take this information into account. Native SQL
does not support automatic client handling. Instead, you must treat a client
field like any other field
Native SQL and Transactions
One should not use any transaction control statement such as
COMMIT, ROLLBACK WORK, or any statements that set transaction parameters using
Native SQL to ensure that transaction in the R/3 System are consistent.
ABAP Dictionary
The ABAP Dictionary is nothing but a part of the ABAP
Workbench. It allows you to create and administer database tables. There are no
statements from the DDL part of Standard SQL in Open SQL. It should be noted
that normal application programs should not create or change their own database
tables.
To create and change database tables, the ABAP Dictionary
has to use the DDL part of Open SQL. Besides this, it also administers the ABAP
Dictionary in the database. In addition, the ABAP Dictionary contains meta-descriptions
of all database tables in the R/3 system. Here, only database tables appears in
the Dictionary, which you have created using the ABAP Dictionary. Open SQL
statements can only access tables, which exists in the ABAP Dictionary.
Authorization and Consistency Checks
With regard to authorization and consistency checks, the DCL
part of Standard SQL is not used in R/3 programs. Whereas, the work processes
which are within the R/3 system are logged into the database system as users
with full rights. By using the R/3 authorization concept, the authorizations of
programs or users to read or change database tables is administered within the
R/3 system. In addition, transactions must equally ensure their own data
consistency using the R/3 locking concept.
The R/3 lock concept allows you to monitor your system with
regards to lock logics. The R/3 lock concept works closely together with the
R/3 updates.
As an example, say that a travel agent wants to book a
flight for a customer who wants to fly to a particular city with a certain
airline on a certain day. If there are still available seats on the flight,
then the booking will be possible, otherwise it will lead to overbooking.
Hence, the database entry corresponding to the flight must be locked against
access from other transactions to avoid the possibility of overbooking. This is
because two agents might both be doing this same thing at the same time, and we
need to make sure that we don't overbook.