http://www.stechno.net/sap-notes.html?

view=sapnote&id=323151
http://www.dataxstream.com/2010/05/using-native-sql-in-an-abap-proxy/
***********************************************************************
TABLES dd02t.
SELECT-OPTIONS tabname FOR dd02t-tabname.
DATA:wa_tab LIKE dd02t,
i_tab LIKE TABLE OF dd02t.
EXEC SQL.
OPEN C FOR
SELECT *
FROM dd02t
WHERE ddlanguage <b>=</b> :sy-langu
ENDEXEC.
DO.
EXEC SQL.
FETCH NEXT C INTO :wa_tab
ENDEXEC.
IF sy-subrc <> 0.
EXIT.
ENDIF.
APPEND wa_tab TO i_tab.
ENDDO.
EXEC SQL.
CLOSE C
ENDEXEC.
SORT i_tab BY tabname.
DELETE i_tab WHERE NOT
tabname IN tabname.
********************************************************************************
***
DATA carrid_wa TYPE scarr-carrid.
DATA dbtype TYPE dbcon_dbms.
SELECT SINGLE dbms
FROM dbcon
INTO dbtype
WHERE con_name = dbs.
IF dbtype = 'ORA'.
TRY.
EXEC SQL.
CONNECT TO :dbs
ENDEXEC.
IF sy-subrc <> 0.
RAISE EXCEPTION TYPE cx_sy_native_sql_error.
ENDIF.
EXEC SQL.
OPEN dbcur FOR
SELECT carrid
FROM scarr

WHERE mandt = :sy-mandt

ENDEXEC.
DO.
EXEC SQL.
FETCH NEXT dbcur INTO :carrid_wa
ENDEXEC.
IF sy-subrc <> 0.
EXIT.
ELSE.
WRITE / carrid_wa.
ENDIF.
ENDDO.
EXEC SQL.
CLOSE dbcur
ENDEXEC.
EXEC SQL.
DISCONNECT :dbs
ENDEXEC.
CATCH cx_sy_native_sql_error.
MESSAGE `Error in Native SQL.` TYPE 'I'.
ENDTRY.
ENDIF.
********************************************************************************
*
Symptom
This note describes the option (available as of Basis Release 4.0B) of using Nat
ive SQL language elements (statements) to establish one or several database (DB)
connections to database systems of the same manufacturer (homogeneous multiconn
ect) or to databases of other manufacturers (heterogeneous multiconnect). Howeve
r, a heterogeneous multiconnect is possible only as of Basis Release 4.5B.
Other terms
Multiconnect, DBCON, Native SQL, EXEC SQL, connect
Solution
When you start an R/3 application server, a connection is opened by default from
the R/3 kernel to the R/3 database. In the following, this connection is referr
ed to as R/3 default connection. All SQL statements that are executed by the R/3
kernel or by ABAP programs - regardless of whether they are Open SQL statements
or Native SQL statements - automatically refer to this default connection, that
is, they run in the context of the active DB transaction on this connection. Th
e connection data (such as the DB user name, password of the user, or the databa
se name) is derived either from the profile parameters or from the environment v
ariables that are set accordingly (this is DB-specific).
As of Release 4.0B, you have the option of opening other DB connections in addit
ion to the default connection from within an ABAP program, and you can access th
ese databases using Native SQL statements. These additional connections can be s
et up either
to the standard R/3 database or
to another database of the same DB manufacturer or
to a database of a different DB manufacturer (as of Release 4.5B).
These databases do not necessarily have to contain SAP components. However, yo
u can only set up connections to database systems that are also supported by the
R/3 Basis system. These are DB2, Informix, MS SQL Server, Oracle, and SAP DB. I
f you only want to set up connections to databases of the same manufacturer (tha
t is, set up homogeneous connections only), this is already possible using the d

elivered R/3 software. However, if you want to set up a connection to a database

that does not correspond to the DB platform of the R/3 database, you must also
install a DB-platform-specific DLL that can be used to route accesses to this da
tabase from R/3. These DLLs are not part of a standard R/3 installation. In this
case, contact your SAP consultant. You can find information about potential pla
tform-specific restrictions in the attached special notes.
Configuration: the table DBCON
Before you can open an additional DB connection, all connection data that is req
uired for identifying the target database and for the authentication against thi
s database must be communicated to the ABAP runtime environment. To do this, cre
ate an entry in the table DBCON that contains all of the required connection dat
a for each database connection that you want to set up in addition to the R/3 de
fault connection. The table DBCON is in the R/3 default database and can be main
tained using the table maintenance tool (transaction SM30) or, as of Release 4.6
, using transaction DBCO. For each connection you must enter the following infor
mation in this table:
A logical connection name. The name entered here explicitly identifies a databas
e connection.
The database type. This determines which DB platform will be used for this conne
ction. In principle, you can enter all DB platforms supported by the R/3 System.
The database user under whose name you want to set up the connection.
The password of this user for authentication against the database. This password
is stored in encrypted form.
The technical connection data required to set up the connection to the database.
The connection data is DB platform-dependent and generally includes the databas
e name as well as the DB host on which the database runs.
Native SQL statements to administrate several database connections
Only Native SQL interfaces allow you to set up additional database connections a
nd to also access non-R/3 databases. However, all Open SQL statements will conti
nue to be transferred to the default connection, that is, to the R/3 database.
Statements for opening, closing, and setting up a database connection have been
added to Native SQL. If a new database connection is opened, a new DB transactio
n is started automatically on this connection. This transaction is independent o
f the transaction currently running on the R/3 default connection, that is, the
transaction running there is not closed and all subsequent Open SQL statements w
ill continue to be processed in this transaction (and not in the transaction sta
rted on the new DB connection). However, all subsequent Native SQL statements wi
ll be executed on the newly opened connection. No synchronization is carried out
by the system between the transactions running on the different connections, th
at is, no 2-phase commit log is supported.
Opening a database connection
EXEC SQL.
CONNECT TO <con_name> [ AS <alias_name> ]
ENDEXEC.
This statement opens the database connection called <con_name>. In this context,
<con_name> is a user-defined logical name under which all of the information re
quired to open the database connection (such as the user name, password, databas
e name, and so on) must be stored in the table DBCON. You can specify <con_name>
as a string literal or as a variable in the form :<var>.
If the addition "AS <alias_name>" is specified, the open database connection is

managed with the indicated alias name. If no alias name is specified, <con_name>
is used as the identification for the open connection. If you enter different a
lias names, you can open several connections to the same database simultaneously
by using the same user ID. This alias mechanism allows the execution of indepen
dent transactions on the same logical database connection (see example 2). The a
lias name can also be entered as a literal or as a variable.
If no entry is found in the table DBCON for the indicated connection name <con_n
ame>, an ABAP runtime error occurs. If, on the other hand, the connection setup
fails due to a DB error, for example, because the relevant database is not onlin
e, then SY-SUBRC = 4 is set and the ABAP program assumes control.
After the connection has been successfully set up (SY-SUBRC = 0), the connection
that was just opened automatically turns into the active connection, that is, f
rom this point on, all subsequent Native SQL statements (and only these) will ac
cess the database associated with this connection. However, all subsequent Open
SQL accesses still refer to the default connection. If the connection is not clo
sed explicitly using a "DISCONNECT" statement (see below), it remains open until
it is closed implicitly when the corresponding internal session is closed (the
term "internal session" is explained in the section on "Data area and Modulariza
tion Unit Organization" in the ABAP online documentation). After that, you can a
ccess this connection only if it has been opened again explicitly using a new "C
ONNECT" statement.
Note:
If a database connection that was opened using a "CONNECT" statement is not expl
icitly closed again using a "DISCONNECT" statement, it is invalidated (this mean
s that it will have to be opened again using a "CONNECT" for further accesses) w
hen the internal session is closed, but the physical connection remains. The adv
antage of this is that it will not have to be set up again if a new "CONNECT" is
executed. However, "reusing" a connection that was previously opened works only
if there are no open transactions on this connection, that is, if the last tran
saction on this connection was completed using COMMIT or ROLLBACK.
Setting the active database connection
EXEC SQL.
SET CONNECTION { <alias_name> | DEFAULT }
ENDEXEC.
This statement sets the data base connection <alias_name> that has been opened t
o active. This means that all subsequent Native SQL statements are executed on t
his connection. If a transaction is still open on the previous connection, it re
mains open and can later be continued by reverting to this connection.
You can also enter the keyword DEFAULT as an alias name. This causes the R/3 def
ault connection to turn into the active connection again.
Again, <alias_name> can be entered directly as a literal or as a variable value
in form of :<var>. However, the entered alias name must be known from a precedin
g "CONNECT" statement (that is, a statement executed within the same internal mo
de). If the database connection was opened without explicitly specifying an alia
s name, the connection name <con_name> must be used in the "SET" statement as th
e <alias_name>.
If there is no opened connection for the entered connection name, SY-SUBRC = 4 i
s set.
Disconnecting a database connection

EXEC SQL.
DISCONNECT <alias_name>
ENDEXEC.
The "DISCONNECT" statement explicitly closes a database connection opened under
the <alias_name> name. As of Basis Release 6.20, the following applies: The tran
saction running on this connection is rolled back. Before Release 6.20, the phys
ical connection is retained if the transaction running on this connection was no
t completed by COMMIT/ROLLBACK. After a "DISCONNECT", you can no longer access t
his connection until it is reopened explicitly by a "CONNECT". If the closed con
nection was also the connection that was just active, the R/3 default connection
automatically turns into the active connection again.
The "DISCONNECT" statement also closes the physical connection to the database.
If you are setting up a new connection, you must first re-establish this physica
l connection, which may be a rather time-consuming operation because the relevan
t system resources will have to be requested for the client as well as for the d
atabase server. Therefore, you should explicitly close a connection using the "D
ISCONNECT" statement only if you want the actions executed on this connection to
run only occasionally. However, if you want to use this connection permanently,
it should remain open.
If the <alias_name> does not correspond to any previously opened DB connection,
an ABAP runtime error occurs.
Example 1: Accessing remote DB in a subroutine
FORM remote_access USING con_name LIKE dbcon-con_name.
* This form performs some database operations on connection 'con_name'.
* The form does not require that the caller has already opened this
* connection nor does it require that 'con_name' is "active". After
* the form has finished the "default connection" is active
* Test if connection 'con_name' has already been opened
EXEC SQL.
SET CONNECTION :con_name
ENDEXEC.
IF SY-SUBRC <> 0.
* Connection not yet opened.
EXEC SQL.
CONNECT TO :con_name
ENDEXEC.
IF SY-SUBRC <> 0.
*
error handling
ENDIF.
ENDIF.
* Do something on connection 'con_name'
EXEC SQL.
...
ENDEXEC.
* Commit the changes on 'con_name'
EXEC SQL.
COMMIT
ENDEXEC.
* Reset to "default connection"
EXEC SQL.
SET CONNECTION DEFAULT

ENDEXEC.
ENDFORM.
Example 2: Executing independent transactions
DATA con_name LIKE dbcon-con_name VALUE 'ABC'.
* Open a connection C1 to a database identified by the logical name
* 'ABC'. This implicitly starts a transaction T1.
EXEC SQL.
CONNECT TO :con_name AS 'C1'
ENDEXEC.
IF SY-SUBRC <> 0.
* error handling
ENDIF.
* Do some database operations on connection C1
EXEC SQL.
...
ENDEXEC.
* Open a second connection C2 to the same database 'ABC'. This
* implicitly starts transaction T2 which became the "active" one.
* Transaction T1 still remains open.
EXEC SQL.
CONNECT TO :con_name AS 'C2'
ENDEXEC.
IF SY-SUBRC <> 0.
* error handling
ENDIF.
* Do some operations on connection C2
EXEC SQL.
...
ENDEXEC.
* Commit transaction T2. This commit does not have any effect on
* transaction T1.
EXEC SQL.
COMMIT
ENDEXEC.
* Resume transaction T1 on connection C1
EXEC SQL.
SET CONNECTION 'C1'
ENDEXEC.
EXEC SQL.
...
ENDEXEC.
* Commit transaction T1 on connection C1
EXEC SQL.
COMMIT
ENDEXEC.
* Reset to the default connection
EXEC SQL.
SET CONNECTION DEFAULT

ENDEXEC.