Get Example source ABAP code based on a different SAP table
Database Access Using Secondary Connections and Service Connections Secondary connections and service connections are opened and used in different ways in AB_SQL , Native SQL, and AMDP. A secondary or service connection active for an ABAP_ISESS can be shared by AB_SQL , Native SQL, or AMDP. Connections used by AB_SQL , however, cannot have any lowercase letters in their names and ADBC can reserve connections for itself exclusively. ITOC
AB_SQL The following additions can be used to use a database connection other than the standard connection in AB_SQL :
The addition CONNECTION for read statements
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 AB-SQL statement, the following applies:
If the specified connection is not yet active in the current ABAP_ISESS , 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 AB_SQL , Native SQL, or AMDP.
If the specified connection is already active in the current ABAP_ISESS , the AB-SQL statement uses this connection and works in its database LUW. The connection can be activated using AB_SQL , Native SQL, or AMDP. When a secondary connection is used, an AB-SQL statement only accesses the database schema assigned to the database user name assigned to the secondary connection. AB_SQL 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, AB_SQL 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 AB-SQL statement can reuse database connections active in Native SQL or AMDP only if their names do not contain any lowercase letters.
Latest notes:
The type of a database object specified in an AB-SQL 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 AB-SQL 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 AB_SQL 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. ABAP_HINT_END
Example ABAP Coding
Specification of a database connection in AB_SQL . ABEXA 01187 ABAP_EXAMPLE_END
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 AB_SQL , 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 ABAP_ISESS , 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 ABAP_ISESS , this connection and its database LUW are used. The connection can be activated using AB_SQL , Native SQL, or AMDP.
GET_CONNECTION with abap_false passed to SHARABLE (default): A new connection is always activated for the current ABAP_ISESS 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.
Latest 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 AB_SQL 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 ABAP_ISESS . 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. ABAP_HINT_END
Example ABAP Coding
Specification of a database connection in ADBC. ABEXA 01188 ABAP_EXAMPLE_END
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
CONNECT TO
SET CONNECTION 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 ABAP_ISESS , 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 AB_SQL , Native SQL, and AMDP.
If the connection specified after CON_NAME is already active in the current ABAP_ISESS , this connection and its database LUW are reused. The connection can be activated using AB_SQL , 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 ABAP_ISESS , 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. AB_SQL 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 ABAP_ISESS , 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 ABAP_ISESS 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 ABAP_ISESS . 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.
Latest notes: 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 ABAP_ISESS . These are indicated in the output of the program DBCONINFO by the different values in the column Hdl. ABAP_HINT_END
Example ABAP Coding
Specification of a database connection after EXEC SQL. ABEXA 01189 ABAP_EXAMPLE_END
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 ABAP_ISESS , 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 AB_SQL , Native SQL, and AMDP.
If the specified connection is already active in the current ABAP_ISESS , the procedure implementation is called using this connection and works in its database LUW. The connection can be activated using AB_SQL , Native SQL, or AMDP.
Latest notes: The service connections that can be used by AMDP are also connections that can be used by AB_SQL , Native SQL, and AMDP, as long as the appropriate conditions are met. ABAP_HINT_END
Example ABAP Coding
Specification of a database connection in AMDP. ABEXA 01190 ABAP_EXAMPLE_END
Interaction of AB_SQL , Native SQL, and AMDP A secondary connection or service connection active within an ABAP_ISESS is shared by AB_SQL , 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 AB-SQL 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 ABAP_ISESS is used subsequently in AB_SQL , 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 AB_SQL , it is opened again implicitly. If a closed connection is reused in Native SQL or AMDP an exception is raised.
Latest notes: When sharing database connections, it should be noted that the name of a database connection is always converted to uppercase letters in AB_SQL . In Native SQL and AMDP, on the other hand, the name is case-sensitive. To access a database connection activated in AB_SQL in Native SQL or AMDP, the connection must be specified in uppercase letters. Conversely, an AB-SQL 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. ABAP_HINT_END
Example ABAP Coding
Use of a shared service connection in ADBC and AB_SQL . 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. ABEXA 01191 ABAP_EXAMPLE_END
