Kontakt

Ansicht
Dokumentation

ABENDB_CONNECTIONS_USING - DB CONNECTIONS USING

ABENDB_CONNECTIONS_USING - DB CONNECTIONS USING

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   Vendor Master (General Section)  
This documentation is copyright by SAP AG.
SAP E-Book

Database Access Using Secondary Connections and Service Connections

Secondary connections and service connections are opened and used in different ways in , Native SQL, and AMDP. A secondary or service connection active for an internal session can be shared by , Native SQL, or AMDP. Connections used by , however, cannot have any lowercase letters in their names and ADBC can reserve connections for itself exclusively.

The following additions can be used to use a database connection other than the standard connection in :

  • The identical addition CONNECTION for write statements

If the addition CONNECTION is specified using the name of a secondary connection from the database table DBCON or using the name of a service connection in an statement, the following applies:

  • If the specified connection is not yet active in the current internal session, it is either opened and given the state active or, if an open inactive connection exists for the current work process, it is reused and set to active. When the connection is activated, a database LUW is opened for it and this can be used by , Native SQL, or AMDP.
  • If the specified connection is already active in the current internal session, the statement uses this connection and works in its database LUW. The connection can be activated using , Native SQL, or AMDP.

When a secondary connection is used, an statement only accesses the database schema assigned to the database user name assigned to the secondary connection. can only access database tables and views that are defined in the ABAP Dictionary in the current AS ABAP, which means that every database table or view accessed using a secondary connection must exist and be active as a database or view with the same name and matching DDIC structure in the current AS ABAP, regardless of the secondary database and database schema. For the database tables or views of the secondary database, assumes that their table category and type information matches the local definition exactly. This prerequisite is essential, for example, for the correct interpretation of the database content and, if necessary, their conversion with respect to the ABAP types of the target fields. If this prerequisite is not met, incorrect data or runtime errors can be caused by reads or writes depending on the database system. Because the ABAP runtime framework cannot ensure the consistency of the type descriptions in the local and remote databases, the consistency must be guaranteed by the relevant application program.

The name of a secondary connection or service connection specified after CONNECTION is transformed into uppercase letters internally. This must be respected when Native SQL accesses the connection explicitly. Conversely, an statement can reuse database connections active in Native SQL or AMDP only if their names do not contain any lowercase letters.

Notes

  • The type of a database object specified in an statement using the addition CONNECTION does not necessarily need to match the type of the database object with the same name in the secondary database. For example, a view with the same name in the secondary database can be accessed by specifying a database table and vice versa if they have the same structure.
  • If a database table specified using the addition CONNECTION in an statement is a global temporary table (GTT), it is handled like a GTT, even if it is a regular transparent table in the secondary database. Conversely, there is no special handling in if the database is a GTT on the secondary database only.
  • The prerequisite that an identically named database object with a suitable DDIC structure must exist in the current system for views accessed using a secondary connection is particularly important for DDIC external views.

Example

Specification of a database connection in .

Native SQL - ADBC

To use a database connection other than the standard connection in ADBC, the static method GET_ABAP_CONNECTION of the class CL_SQL_CONNECTION can be used. The return value of the method is a reference to a connection object that can be passed to other ADBC objects. Using the input parameter CON_NAME, the method can be passed the name of a secondary connection from the database table DBCON or a service connection. These names are case-sensitive. The activated connection can be used in , Native SQL, and AMDP. A further method GET_CONNECTION works in a similar way to GET_ABAP_CONNECTION, but has an additional input parameter SHARABLE, which defines how any active secondary connections and service connections are reused. If abap_true is passed to SHARABLE, GET_CONNECTION works in exactly the same way as GET_ABAP_CONNECTION.

  • GET_ABAP_CONNECTION or GET_CONNECTION with abap_true passed to SHARABLE:
  • If the connection passed to CON_NAME is not yet active in the current internal session, it is either opened and set to active or, if an open inactive connection exists for the current work process, it is reused and set to active. When the connection is activated, a database LUW is opened for it.

  • If the connection passed to CON_NAME is already active in the current internal session, this connection and its database LUW are used. The connection can be activated using , Native SQL, or AMDP.

  • GET_CONNECTION with abap_false passed to SHARABLE (default):
A new connection is always activated for the current internal session by opening a new connection or activating an inactive connection of the current work process. No existing active connection of the name passed to CON_NAME is used. A connection activated like this can only be used exclusively using the returned connection object in ADBC.

After successful execution, GET_CONNECTION gets a reference to a connection object. The connection object represents the connection activated or reused using GET_CONNECTION in ADBC and can be passed to the instance constructors of the classes CL_SQL_STATEMENT and CL_SQL_PREPARED_STATEMENT. The SQL statements of these classes are then executed on this connection in its database LUW.

Notes

  • abap_false can be used for the parameter SHARABLE of the method GET_CONNECTION to control the use of a database connection and its database LUW explicitly. Database connections that are activated differently are usually available to all accesses in and Native SQL.
  • If abap_false is passed to the parameter SHARABLE of the method GET_CONNECTION, multiple database connections with the same name can be activated and used within a single internal session. These are indicated in the output of the program DBCONINFO by the different values in the column Hdl.
  • When opening exclusive connections for connection objects, the maximum number of connections for each work process must not be exceeded. Exclusive connection should be closed explicitly once they are no longer needed and if there are a large number of connection objects.

Example

Specification of a database connection in ADBC.

Native SQL - EXEC SQL

The following special statements can be used to use a database connection other than the standard connection in Native SQL embedded between EXEC SQL and ENDEXEC

The statement CONNECT TO can be used to activate a secondary connection or a service connection. Here, the addition AS can be used to open the same connection more than once under different names. The entries made here are case-sensitive.

  • If no name is specified using AS, the following applies:
  • If the connection specified after CONNECT TO is not yet active in the current internal session, it is either opened and set to active or, if an open inactive connection exists for the current work process, it is reused and set to active. When the connection is activated, a database LUW is opened for it and this can be used by , Native SQL, and AMDP.

  • If the connection specified after CON_NAME is already active in the current internal session, this connection and its database LUW are reused. The connection can be activated using , Native SQL, or AMDP.

  • If a name is specified using AS, the following applies:
  • If the connection specified after CONNECT TO is not yet active under this name in the current internal session, it is either opened and set to active or, if an open inactive connection exists for the current work process, it is reused and given the state active. When the connection is activated, a database LUW is opened for it. A connection with a name defined using AS is only used by Native SQL embedded between EXEC SQL and ENDEXEC. and other kinds of Native SQL or AMDP do not use this type of connection.

  • If the connection specified after CON_NAME is already active under this name in the current internal session, this connection and its database LUW are reused. The connection can only have been activated using CONNECT TO.

After the statement CONNECT TO, all subsequent Native SQL statements embedded between EXEC SQL and ENDEXEC in the current internal session use the connection activated or reused using CONNECT TO. The statement SET CONNECTION can be used to switch to the use of the previously activated connection of the current internal session. Here, a name defined with AS must be specified using this connection. More specifically, the standard connection can be activated by specifying DEFAULT. The statement SET CONNECTION is ignored by the database LUWs of the connections involved.

Note

When a name is specified after AS in the statement CONNECT TO, multiple database connections with the same original name can be activated and used in the same internal session. These are indicated in the output of the program DBCONINFO by the different values in the column Hdl.

Example

Specification of a database connection after EXEC SQL.

AMDP

To use a database connection other than the standard connection to execute an AMDP procedure implementation, the names of service connections can be passed to the input parameter CONNECTION of the associated AMDP method. The names are case-sensitive here. Secondary connections cannot be used.

  • If the passed connection is not yet active in the current internal session, it is either opened and set to active or, if an open inactive connection exists for the current work process, it is reused and set to active. When the connection is activated, a database LUW is opened for it and this can be used by , Native SQL, and AMDP.
  • If the specified connection is already active in the current internal session, the procedure implementation is called using this connection and works in its database LUW. The connection can be activated using , Native SQL, or AMDP.

Note

The service connections that can be used by AMDP are also connections that can be used by , Native SQL, and AMDP, as long as the appropriate conditions are met.

Example

Specification of a database connection in AMDP.

Interaction of , Native SQL, and AMDP

A secondary connection or service connection active within an internal session is shared by , Native SQL, and AMDP with the following exceptions:

  • A connection activated using ADBC that uses the value abap_false for the parameter SHARABLE of the method GET_CONNECTION of the class CL_SQL_CONNECTION can only be used exclusively using the associated connection object.
  • A connection activated after EXEC SQL with CONNECT TO using a name specified after AS can only be used between EXEC and ENDEXEC.
  • AMDP can only use service connections.

Shared connections are activated as follows:

  • Using the CONNECTION addition of statements to activate the connection
  • Using either the method GET_ABAP_CONNECTION of the ADBC class CL_SQL_CONNECTION or the method GET_CONNECTION to activate the connection. The value abap_true is used for the parameter SHARABLE here.
  • Passing the name to the input parameter CONNECTION of an AMDP method to activate the connection.
  • Using the statement CONNECT TO after EXEC SQL to activate the connection, without specifying a name after AS.

When a shared connection is activated, it is reused whenever the same internal session is used subsequently in , Native SQL, and AMDP, regardless of how it is activated.

Shared connections can be closed using Native SQL, as shown above. The connection can then no longer be used. When a closed connection is specified in , it is opened again implicitly. If a closed connection is reused in Native SQL or AMDP an exception is raised.

Note

When sharing database connections, it should be noted that the name of a database connection is always converted to uppercase letters in. In Native SQL and AMDP, on the other hand, the name is case-sensitive. To access a database connection activated in in Native SQL or AMDP, the connection must be specified in uppercase letters. Conversely, an statement cannot use a database connection activated using Native SQL AMDP if its name contains lowercase letters. This mainly affects service connections and names defined using the addition AS of the statement CONNECT TO. Secondary connections, on the other hand, must be specified in uppercase letters in Native SQL too in accordance with their spelling in the table DBCON.

Example

Use of a shared service connection in ADBC and . The modifying statements are executed in a database LUW. If the name of the service connection were to contain lowercase letters or if the method GET_CONNECTION with the value abap_false were used for the parameter SHARABLE in ADBC, separate connections with two different database LUWs would be produced. Accessing the same database table would then usually cause a lock situation.






Fill RESBD Structure from EBP Component Structure   TXBHW - Original Tax Base Amount in Local Currency  
This documentation is copyright by SAP AG.

Length: 21898 Date: 20240425 Time: 005937     sap01-206 ( 312 ms )