Академический Документы
Профессиональный Документы
Культура Документы
1
DATABASE MULTICONNECT WITH EXEC SQL...................................................2
Secondary Database Connections with Open SQL.......................................................6
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 ).
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!
< SID >: System ID of the SAP System, for example PRD
Client SAP System: SAP system from which you want to access the Remote-DB server.
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).
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:
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
* Execution of DB operations
EXEC SQL.
...
ENDEXEC.
EXEC SQL.
COMMIT WORK
ENDEXEC.
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:
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.