EXEC SQL

Embed Size (px)

Citation preview

  • 8/9/2019 EXEC SQL

    1/7

    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 FORSELECT *FROM dd02tWHERE ddlanguage = :sy-languENDEXEC.

    DO.EXEC SQL. FETCH NEXT C INTO :wa_tabENDEXEC.IF sy-subrc 0.

    EXIT.ENDIF.APPEND wa_tab TO i_tab.ENDDO.

    EXEC SQL.CLOSE CENDEXEC.

    SORT i_tab BY tabname.DELETE i_tab WHERE NOTtabname IN tabname.********************************************************************************

    ***

    DATA carrid_wa TYPE scarr-carrid.

    DATA dbtype TYPE dbcon_dbms.

    SELECT SINGLE dbmsFROM dbconINTO dbtypeWHERE 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 FORSELECT carrid

    FROM scarr

  • 8/9/2019 EXEC SQL

    2/7

    WHERE mandt = :sy-mandtENDEXEC.DO.

    EXEC SQL.FETCH NEXT dbcur INTO :carrid_wa

    ENDEXEC.IF sy-subrc 0.EXIT.

    ELSE.WRITE / carrid_wa.

    ENDIF.ENDDO.EXEC SQL.

    CLOSE dbcurENDEXEC.EXEC SQL.

    DISCONNECT :dbsENDEXEC.

    CATCH cx_sy_native_sql_error.MESSAGE `Error in Native SQL.` TYPE 'I'.

    ENDTRY.ENDIF.*********************************************************************************

    SymptomThis note describes the option (available as of Basis Release 4.0B) of using Native SQL language elements (statements) to establish one or several database (DB)connections to database systems of the same manufacturer (homogeneous multiconnect) or to databases of other manufacturers (heterogeneous multiconnect). However, a heterogeneous multiconnect is possible only as of Basis Release 4.5B.

    Other termsMulticonnect, DBCON, Native SQL, EXEC SQL, connect

    SolutionWhen 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 referred to as R/3 default connection. All SQL statements that are executed by the R/3kernel or by ABAP programs - regardless of whether they are Open SQL statementsor Native SQL statements - automatically refer to this default connection, thatis, they run in the context of the active DB transaction on this connection. The connection data (such as the DB user name, password of the user, or the database name) is derived either from the profile parameters or from the environment variables that are set accordingly (this is DB-specific).

    As of Release 4.0B, you have the option of opening other DB connections in addition to the default connection from within an ABAP program, and you can access these databases using Native SQL statements. These additional connections can be set up either

    to the standard R/3 database orto another database of the same DB manufacturer orto a database of a different DB manufacturer (as of Release 4.5B).

    These databases do not necessarily have to contain SAP components. However, you can only set up connections to database systems that are also supported by theR/3 Basis system. These are DB2, Informix, MS SQL Server, Oracle, and SAP DB. If you only want to set up connections to databases of the same manufacturer (that is, set up homogeneous connections only), this is already possible using the d

  • 8/9/2019 EXEC SQL

    3/7

    elivered R/3 software. However, if you want to set up a connection to a databasethat does not correspond to the DB platform of the R/3 database, you must alsoinstall a DB-platform-specific DLL that can be used to route accesses to this database from R/3. These DLLs are not part of a standard R/3 installation. In thiscase, contact your SAP consultant. You can find information about potential platform-specific restrictions in the attached special notes.

    Configuration: the table DBCONBefore you can open an additional DB connection, all connection data that is required for identifying the target database and for the authentication against this database must be communicated to the ABAP runtime environment. To do this, create an entry in the table DBCON that contains all of the required connection data for each database connection that you want to set up in addition to the R/3 default connection. The table DBCON is in the R/3 default database and can be maintained using the table maintenance tool (transaction SM30) or, as of Release 4.6, using transaction DBCO. For each connection you must enter the following information in this table:

    A logical connection name. The name entered here explicitly identifies a database connection.The database type. This determines which DB platform will be used for this connection. 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 passwordis 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 database 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 and to also access non-R/3 databases. However, all Open SQL statements will continue 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 transaction is started automatically on this connection. This transaction is independent of the transaction currently running on the R/3 default connection, that is, thetransaction running there is not closed and all subsequent Open SQL statements will continue to be processed in this transaction (and not in the transaction started on the new DB connection). However, all subsequent Native SQL statements will be executed on the newly opened connection. No synchronization is carried outby the system between the transactions running on the different connections, that is, no 2-phase commit log is supported.

    Opening a database connection

    EXEC SQL.

    CONNECT TO [ AS ]ENDEXEC.

    This statement opens the database connection called . In this context, is a user-defined logical name under which all of the information required to open the database connection (such as the user name, password, database name, and so on) must be stored in the table DBCON. You can specify as a string literal or as a variable in the form :.

    If the addition "AS " is specified, the open database connection is

  • 8/9/2019 EXEC SQL

    4/7

    managed with the indicated alias name. If no alias name is specified, is used as the identification for the open connection. If you enter different alias names, you can open several connections to the same database simultaneouslyby using the same user ID. This alias mechanism allows the execution of independent transactions on the same logical database connection (see example 2). The alias 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 , an ABAP runtime error occurs. If, on the other hand, the connection setupfails due to a DB error, for example, because the relevant database is not online, then SY-SUBRC = 4 is set and the ABAP program assumes control.

    After the connection has been successfully set up (SY-SUBRC = 0), the connectionthat was just opened automatically turns into the active connection, that is, from this point on, all subsequent Native SQL statements (and only these) will access the database associated with this connection. However, all subsequent OpenSQL accesses still refer to the default connection. If the connection is not closed explicitly using a "DISCONNECT" statement (see below), it remains open untilit is closed implicitly when the corresponding internal session is closed (theterm "internal session" is explained in the section on "Data area and Modularization Unit Organization" in the ABAP online documentation). After that, you can access this connection only if it has been opened again explicitly using a new "CONNECT" statement.

    Note:If a database connection that was opened using a "CONNECT" statement is not explicitly closed again using a "DISCONNECT" statement, it is invalidated (this means that it will have to be opened again using a "CONNECT" for further accesses) when the internal session is closed, but the physical connection remains. The advantage of this is that it will not have to be set up again if a new "CONNECT" isexecuted. However, "reusing" a connection that was previously opened works onlyif there are no open transactions on this connection, that is, if the last transaction on this connection was completed using COMMIT or ROLLBACK.

    Setting the active database connection

    EXEC SQL.

    SET CONNECTION { | DEFAULT }ENDEXEC.

    This statement sets the data base connection that has been opened to active. This means that all subsequent Native SQL statements are executed on this connection. If a transaction is still open on the previous connection, it remains 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 default connection to turn into the active connection again.

    Again, can be entered directly as a literal or as a variable valuein form of :. However, the entered alias name must be known from a precedin

    g "CONNECT" statement (that is, a statement executed within the same internal mode). If the database connection was opened without explicitly specifying an alias name, the connection name must be used in the "SET" statement as the .

    If there is no opened connection for the entered connection name, SY-SUBRC = 4 is set.

    Disconnecting a database connection

  • 8/9/2019 EXEC SQL

    5/7

    EXEC SQL. DISCONNECT ENDEXEC.

    The "DISCONNECT" statement explicitly closes a database connection opened underthe name. As of Basis Release 6.20, the following applies: The transaction running on this connection is rolled back. Before Release 6.20, the physical connection is retained if the transaction running on this connection was not completed by COMMIT/ROLLBACK. After a "DISCONNECT", you can no longer access this connection until it is reopened explicitly by a "CONNECT". If the closed connection was also the connection that was just active, the R/3 default connectionautomatically 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 physical connection, which may be a rather time-consuming operation because the relevant system resources will have to be requested for the client as well as for the database server. Therefore, you should explicitly close a connection using the "DISCONNECT" statement only if you want the actions executed on this connection torun only occasionally. However, if you want to use this connection permanently,it should remain open.

    If the 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

  • 8/9/2019 EXEC SQL

    6/7

    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 handlingENDIF.

    * Do some database operations on connection C1EXEC 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 handlingENDIF.

    * Do some operations on connection C2EXEC SQL....ENDEXEC.

    * Commit transaction T2. This commit does not have any effect on* transaction T1.EXEC SQL. COMMITENDEXEC.

    * Resume transaction T1 on connection C1EXEC SQL. SET CONNECTION 'C1'ENDEXEC.

    EXEC SQL....

    ENDEXEC.

    * Commit transaction T1 on connection C1EXEC SQL. COMMITENDEXEC.

    * Reset to the default connectionEXEC SQL. SET CONNECTION DEFAULT

  • 8/9/2019 EXEC SQL

    7/7

    ENDEXEC.