Connecting to external database....................................................................................

1
DATABASE MULTICONNECT WITH EXEC SQL...................................................2
Secondary Database Connections with Open SQL.......................................................6

Connecting to external database

Posted by Horacio Zapettini on 11/3/2005 8:19:00 AM
Hi Mohamed,
What type of external database are you trying to connect to? and What is your sap configuration
and DBserver?
I'm asking because we were able to connect sap (running on solaris and informix to an external
informix, but we weren't able to use dbcon to connect our sap system to an mssql server
external. To connect INFORMIX to MSSQLSERVER we had to develope our own routines, and
they have many drawbacks (like, for example, we aren't able to connect the databases in
background, and the performance in this case isn't the best).
The reason isn't so clear, but it has to do with Operating system issues.

A good hint is to go to services.sap.com, and search for OSS Notes that have exec sql and your
external db.

In our case, we had to work on the basis side to get access rights to the dbserver, we had to
make some changes in the Op.System configuration (so it was aware of the external database
location, I 'm not basis, but that was all what our basis people told me ).

We're using this logic to connect sap to an external informix db:

data: database like dbcon-con_name
...
database = 'INFORMIXEXTERNAL'. "replace it with the name you're using in dbco ->
connection name
EXEC SQL.
connect to :database as 'CON1'
ENDEXEC.
if sy-subrc = 0.
exec sql performing recordset_processing_routine
** HERE YOU HAVE TO WRITE YOUR SELECT / UPDATE / DELETE CODE. THE
USERNAME SPECIFIED IN THE DBCO ENTRY MUST HAVE ACCESS RIGHTS IN THE
EXTERNAL DBSERVER
endexec.
** Once you're done, you have to disconnect. OTherwhise you're generating neverending
processes in the external server.
EXEC SQL.
DISCONNECT 'CON1'
ENDEXEC.
* This is just in case
EXEC SQL.
SET CONNECTION DEFAULT
ENDEXEC.
endif.

You're saying that you get a dump because your SAP isn't able to reach the specified table in
the dbserver. THis issue has to do with three possible problems
1. the user you're using to connect hasn't rights to access the table (you can test it by login in
the external server with that user, and trying to issue the same select with that user in the tool
provided by the database server to run queries.
2. your sap system isn't reaching the external server (basis problem, talk to them in order to
solve it)
3. your dbco isn't properly configured (check oss notes to see how you have to configure it for
your external dbserver)

Otherwise (not 1,2, or 3), check for any oss note that has information about it (as I told you
before, we were able to successfully connect informix -> informix, but due to our system
configuration, we aren't able to connect informix -> mssqlserver. and there is an oss note that
says that we need to have sap running on a windows server in order to make this connection
work properly).

another issue I was running into: neither the connection name in DBCO
nor the external DB name
can have a SPACE in the name!

DATABASE MULTICONNECT WITH EXEC SQL

Nota 146624
This SAP Note describes the possibility of accessing data with EXEC SQL which is not on the SAP database
server but on another AS/400 system.
Other terms
CONNECT DBCON iSeries AS400 DB4 DB2/400 DB400
Solution
Terms
 < NN >: Instance number of the SAP System, for example 00.

 < SID >: System ID of the SAP System, for example PRD

 Remote-DB server: AS/400 system that you want to access.

 Client SAP System: SAP system from which you want to access the Remote-DB server.

 SAP database library: R3< SID >DATA

Basics of the EXEC SQL Multiconnect

OPEN SQL database accesses always refer to the SAP database library. EXEC SQL accesses normally also
refer to the SAP database library. To access data which is on the SAP database server but not in library
R3< SID >DATA, it is sufficient to enter the table name as qualified in EXEC SQL. Example:
EXEC SQL.
SELECT MYFIELD FROM MYLIB/MYTABLE
ENDEXEC.
In your SAP System, you can access data with EXEC SQL which are on other AS/400 systems. From an
SAP System you can only access a database that resides on AS/400.
 For SAP Release 4.5B and higher, there are two possible types of connection: via TCP/IP and via
OptiConnect.

 For SAP Release 4.0B only a connection via TCP/IP is possible It is not possible to use distributed
relational database architecture (DRDA) to access data on other systems from within the
SAP System. Note that accesses via EXEC SQL multiconnect are basically carried out in separate
transactions, that is, there is not a 2-phase commit.

Availability
 For SAP Release 4.0B KERNEL patch level 363 is required.

 For SAP Release 4.5 LIB_DBSL with patch level 0.050 is required.

Preconditions
The operating system release of the remote-DB server must be supported for the client SAP System. On
the remote-DB server, only OS/400 releases are supported which are also supported by IBM. TCP/IP, or as
of Release 4.5B OptiConnect must be installed correctly. The restriction, that all additional connections run
in separate transactions must be taken into account when developing programs. The journaling and the
backing up of data on the remote DB server are not carried out by the SAP System.
Configuration
1. Configuration of the user profile on the AS/400
2. Configuration of the communication on the AS/400
3. Configuration of the connection of table DBCON in the SAP System
1. Configuration of the user profile on the AS/400
For SAP Release 4.6 or higher the instance user or any other user can be used to access the
remote database. The user is entered in table DBCON (see section 'Table DBCON')
For SAP Release 4. 5 and lower only the instance user can be entered.
If you want to enter the instance user and it does not exist on the remote database server,
proceed as follows:
a) Copy objects CRTSAPUSR *CMD and CRTSAPUSR *PGM from the kernel library of
your SAP System to the remote database server.
b) On the remote database server execute command CRTSAPUSR with USER *INST.
Example:
CRTSAPUSR USER(*INST) SID(TST) INSTANCE(00)
where TST is the SAP system ID and 00 the instance.
When using the instance user you have to make sure that the user exists in the client SAP
System and on the remote DB server with identical passwords. When you execute command CRTSAPUSR
the passwords are identical unless it has been changed manually.
If you want to apply another user than the instance user, the following prerequisites have to be
met:
 The SAP Release is 4.6 or higher.

 In the client SAP System, the instance user has to have authority *USE for the user that
accesses the remote-DB. The authority is checked by the SAP kernel.

 The user you chose has to have an identical password for the client SAP System and for
the remote-DB system.

Make sure that the user, whichever you choose, has sufficient authority to access the remote-
DB server successfully. The user needs authorities for the library, for files and possibly for the journal.
The authorization concept for multiconnect has to correspond to the authorization concept of
AS/400: If a user profile (a) has authority *USE for another user profile (b), user profile (a) can call
transaction SBMJOB with user profile (b). The usage of an identical user name and password for the
validation of access authorization is common on the AS/400 database interface (QXDAEDRS/QXDARECVR).

1. Configuration of the communication

For a remote-DB access TCP/IP and OptiConnect are supported. If your local AS/400 is the
remote-DB server, proceed as with a TCP/IP connection.
 OptiConnect

Between the AS/400 systems involved you have to set up and start OptiConnect. In addition, only
in table DBCON an entry on the connection has to exist (see section 'Table DBCON').
 Use of TCP/IP as of OS/400 Release V4R4M0:

a) On the remote-DB server, execute the following command:

STRTCPSVR SERVER(*EDRSQL)
b) Make sure that the job is started
WRKACTJOB SBS(QSYSWRK)
You should see the following job:
QXDAEDRSQL
QUSER
BCH .0 PGM-QXDALISTEN
SELW

To make sure that the job is started automatically after the IPL, add
the command to program QSTRUP as described in SAP Note 77337.
 Use of TCP/IP up to an including for OS/400 Release V4R3M0:

a) Copy the following objects from the kernel library to the remote DB server:
CRTSAPUSR *CMD, CRTSAPUSR *PGM, STARTSAP *CMD, STRRMTDB *PGM, STRSAP
*PGM.
b) Create a library with the name R3400 on the remote DB server and copy the object
R3400/R3RMTDB *JOBD from your client SAP System if the library and the object do not
exist already on your remote-DB system.
c) Create the service table entry sapdbsrv:
ADDSRVTBLE SERVICE('sapdbsrv') PORT(4500) PROTOCOL('tcp')
a) Create user R3SERVER on the remote-DB server.
CRTSAPUSR USER(*SERVER)
a) Provide user R3SERVER with an authorization for program QBFCSETP:
GRTOBJAUT, OBJ(QUSRSYS/QBFCSETP), OBJTYPE(*PGM), USER(R3SERVER), AUT(*USE)
a) Start the database server job on the remote DB server:
STARTSAP *DB
a) To check whether the job is active, enter the following command:
WRKACTJOB SBS(QSYSWRK)
You should see the following job:
R3RMTDB R3SERVER BCH .0 PGM-QBFCLISTEN SELW
a) To make sure that the job is started automatically after the IPL, you can add the
command to the start program QSTRUP as described in SAP Note 77337.
1. Table DBCON
 CON_NAME: freely chosen name of connection. Designated as follows as <con_name>.

 DBMS: DB4

 USER_NAME: The USER_NAME filed is not interpreted on AS/400 before Release 4.6. With
Release 4.6, any AS/400 user can be entered here. The configuration of users on the AS/400 is
described under 'Configuration of the user profile on the AS/400'.

 PASSWORD: You have to enter a password for the SAP System. However, this password is not
interpreted for the AS/400 multiconnect. In this case authority concept of the AS/400, as
described under 'Configuration of the user profile on the AS/400'

 CON_ENV: This field contains the information which is required to set up a remote connection.
On AS/400 you have to enter a character string that should look similar to the following:

<parameter_1>=<value_1>;...;<parameter_n> =<value_n>;
You can enter the following parameter:
 AS4_HOST: Host name of the remote DB server. The parameter AS4_HOST has to be
entered. The host name has to be entered the same way as it is known under TCP/IP or
OptiConnect, depending on the type of connection.

 AS4_DB_LIBRARY: Library which the DB server job should use as current library on the
remote DB server. The parameter AS4_DB_LIBRARY has to be entered.
  AS4_CON_TYPE: Type of connection. Permitted parameters are OPTICONNECT and
SOCKETS. SOCKETS means that that at connection via TCP/IP sockets has been chosen.
Parameter AS4_CON_TYPE is optional. If it is not entered, the system chooses
connection type SOCKETS.

 AS4_NQE_OPTIMIZE_METHOD: performance parameter (all I/O, first I/O), that can only
be used if the release of the target database is greater than or equal to V5R2M0. See
also Note 705888.

 AS4_QAQQINILIB (as of Release 4.6D): specifies the library of the query attribute file
QAQQINI to be used for this connection.
Evidently for the parameter to be effective, the QAQQINI must be in the specified library
on the database host. For more information, see Note 820325.

For a connection via TCP/IP sockets to the remote DB server as0001 in library RMTLIB, the
following entry has to be made in field CON_ENV:
AS4_HOST=as0001;AS4_DB_LIBRARY=RMTLIB;AS4_CON_TYPE=SOCKETS;
The syntax must be exactly as described, that is, there must not be any additional blanks between the
entries. Every entry must end with a semicolon. Only parameter S4_CON_TYPE=SOCKETS; can be left
out.
Programming
 Native SQL commands for management of several database connections

Only via EXEC SQL you can set up additional database connections and use them to access non-
SAP databases from within the SAP System. Native SQL was enhanced by commands for opening and
closing as well as for setting up database connections. These commands are interpreted in the SAP kernel
and therefore not passed on directly to the database. If a new database connection is opened, a new
transaction is automatically started on this connection. This transaction runs independently from currently
running transaction on the SAP default connection, that is, the transaction running is not exited and all the
following OPEN SQL commands refer to this transaction (and not to the transaction started on the new
database connection). However, all the following native SQL commands are then executed on the newly
opened connection. On the system side there is no synchronization between the different connections,
that is, there is not a 2-phase commit.
 Opening a database connection

EXEC SQL. CONNECT [ TO ] < con_name > ENDEXEC.

This command opens the link designated with < con_name > . <con_name > is the name of the
link that must be defined in table DBCON. If the database connection fails because of a database error, no
runtime error is initialized but SY-SUBRC = 4 is set. Until closing or explicitly changing the database
connection, all EXEC SQL accesses refer to this connection. It is the 'active' connection.
 Setting the active database connection

EXEC SQL. SET CONNECTION [ TO ] { < con_name > | DEFAULT } ENDEXEC.

With this command the data base connection is < con_name > set active. This means that all
subsequent native SQL statements on this link are executed. Instead of < con_name > the special value
DEFAULT can also be specified. As a consequence the standard SAP connection becomes the active
connection again.
 Closing a database connection

EXEC SQL. DISCONNECT [ FROM ] < con_name > ENDEXEC.

The DISCONNECT command explicitly closes a database connection previously opened
under the name < con_name >. The current transaction on this connection is rolled back, that is, all
changes made on this connection since the last COMMIT or ROLLBACK via native SQL commands become
ineffective in the database. If you repeatedly want to access a connection, it is advisable for reasons of
performance not to execute a DISCONNECT.
Example
DATA con_name(30) VALUE 'MYCON'.
* Open the link to the database 'MYCON'.
EXEC SQL.
CONNECT TO :con_name
ENDEXEC.
IF SY-SUBRC <> 0.
* Error handling
ENDIF.

* Execution of DB operations
EXEC SQL.
...
ENDEXEC.

EXEC SQL.
COMMIT WORK
ENDEXEC.

* Reset to the standard R /3 link

EXEC SQL.
SET CONNECTION DEFAULT
ENDEXEC.

Secondary Database Connections with Open SQL

You can use the CONNECTION addition to execute Open SQL commands on databases other than
the R/3 standard database. This gives you a number of possibilities, for example you can transfer
and update data in other databases, irrespective of whether the other system is an R/3 System or
not. However, it is a prerequisite that it is a database system supported by SAP, because only in
such a system is the software needed for an Open SQL access available in form of a shared
library.

Setting Up a Secondary Database Connection

To a access another database you need an entry in the table DBCON that describes the access
data of the database. If the secondary database is from a different manufacturer than the R/3
System database, you will need the SAP shared library as well as the client software provided by
the manufacturer. How to create the DBCON entry and install the additional software is described
in the standard SAP Notes for every for every supported database system.

Standard Database Connection

Every work process has a standard database connection to the R/3 standard database. It is
communally used by all internal sessions. You can also explicitly access this database connection
using the name DEFAULT. The DEFAULT connection can also be specified dynamically using
CONNECTION (name), where the name field must have the value 'DEFAULT'.

Accessing Other Database Tables

If you use a database connection to access database tables that are not in the R/3 standard
database, there must also be a database table with the same name and identical type in the ABAP
Dictionary of the local R/3 System. Open SQL assumes that the type information of these remote
database tables corresponds exactly with that of the local database table. This prerequisite is
essential for the correct interpretation of the database contents, for example, and, if necessary,
their conversion with regards to the ABAP type of the target fields (see INTO Clause). If this
prerequisite is not met, this can lead to wrong data or runtime errors when reading or writing,
depending on the database system. Because the ABAP runtime system cannot ensure the
consistency of the type descriptions in the local and remote databases, the consistency must be
guaranteed by the relevant application program.
Database Connections and Transactions
Every database connection forms its own transaction context. This means that database changes
on one connection can be saved (using COMMIT) or discarded (using ROLLBACK) independently of
changes on other database connections. You can, for example, commit and store protocol data on
a secondary database connection without affecting the running transaction on the standard R/3
database connection.

Secondary database connections are not known outside the limits of an internal session. So, if a
program opens a database connection and then calls another program - with SUBMIT for example
- that opens a connection to the same database, you have two different connections and therefore
two different database transactions.

For the first Open SQL commandthat requests a specific database connection, the system opens a
corresponding connection. All subsequent commands (in the same internal session) for the same
remote database use the same database connection and all form a database transaction. The
transaction is ended by:

A COMMIT CONNECTION or ROLLBACK CONNECTION on this

connection

A COMMIT WORK or ROLLBACK WORK

A database commit or database rollback on this database connection in Native SQL,
An implicit commit by a screen change, specifically the statements CALL SCREEN, CALL DIALOG,
CALL TRANSACTION, MESSAGE
A Remote Function Call (RFC), specifically the statements CALL FUNCTION ... DESTINATION, CALL
FUNCTION ... STARTING NEW TASK, CALL FUNCTION ... IN BACKGROUND TASK, and WAIT.

In summary, a database transaction is completed at the latest, when the application program
reaches a state in which a change of work process could occur.

Note:
Working with parallel database connections, that is parallel transactions, can lead to lock
situations that only one work process is involved in: A program changes a database row on the
first connection and tries to change the same row on a second connection. This will result in the
program waiting for the lock of the first program, without this first transaction ever being able to
continue. You can only resolve this situation by ending the work process. This is done
automatically for dialog processes, but must be done manually for background jobs. You should
therefore not change the same table in one program on multiple database connections.

Interaction with Native SQL Connections.

In addition to the above, you can also explicitly open a connection using a CONNECT with Native
SQL. Native SQL also allows you to explicitly close and disconnect a database connection using
DISCONNECT. In this case, the database transaction in question is closed and corresponding
database changes are discarded. You can use the Native SQL command GET CONNECTION to
ascertain the current Native SQL connection. With Native SQL you can also access a connection
that was opened with Open SQL. In this case it is sufficient to convert the active Native SQL
connection using SET CONNECTION. It is not necessary to open it using CONNECT TO.

Managing Database Connections

The database connections are automatically managed by the runtime system. If a transaction is
saved on a database connection (COMMIT) or rolled back (ROLLBACK), it can be reused by the
runtime system. You can open a maximum of 10 database connections for each work process. On
certain databases, you may not be able to reach this number.