A call to SQLFreeHandle() with a HandleType of SQL_HANDLE_DESC frees the descriptor handle in Handle. The call to SQLFreeHandle() does not release any memory allocated by the application that may be referenced by the deferred fields (SQL_DESC_DATA_PTR, SQL_DESC_INDICATOR_PTR, and
SQL_DESC_OCTET_LENGTH_PTR) of any descriptor record of Handle. When an explicitly allocated descriptor handle is freed, all statements that the freed handle had been associated with revert to their automatically allocated descriptor handle.
Note that SQLDisconnect() automatically drops any statements and descriptors open on the connection. When an application frees a statement handle, CLI frees all the automatically generated descriptors associated with that handle.
Chapter 7. Terminating a CLI application
After you have initialized your CLI application and processed transactions, you must terminate the application to properly disconnect from the data source and free resources.
Before you begin
Before terminating your application, you should have initialized your CLI application and completed processing of all transactions.
Procedure
To terminate a CLI application:
1. Disconnect from the data source by calling SQLDisconnect().
2. Free the connection handle by calling SQLFreeHandle() with a HandleType argument of SQL_HANDLE_DBC.
If multiple database connections exist, repeat steps 1 - 2 until all connections are closed and connection handles freed.
3. Free the environment handle by calling SQLFreeHandle() with a HandleType argument of SQL_HANDLE_ENV.
Chapter 8. Trusted connections through DB2 Connect
Some DB2 database servers support trusted contexts. A trusted context allows the database administrator to, among other things, define conditions under which a client application will be allowed to create a trusted connection. A trusted connection is allowed to do things that a normal connection cannot.
There are two types of trusted connection, implicit and explicit. When you create a connection, whether you get an explicit trusted connection, an implicit trusted connection, or a regular connection depends on whether you ask for a trusted connection and whether the connection meets the criteria defined in the trusted context on the server, as summarized in Table 9.
Table 9. What type of connections result from different combinations of actions The connection meets the
server's criteria for being trusted
The connection does not meet the server's criteria for being trusted
You request that the connection be trusted
Explicit trusted connection Regular connection and warning SQL20360W (SQLSTATE 01679) is returned.
You do not request that the connection be trusted
Implicit trusted connection Regular connection
An implicit trusted connection is identical to a regular connection except that it grants temporary role privileges to the user while they are using the connection.
The role privileges that are granted (if any) are specified in the trusted context that caused the connection to be trusted.
Implicit trusted connections can be created by any application that connects using DB2 Connect. Implicit trusted connections are made and used in the same way that regular connections are made and used. This means that no code changes are necessary for an existing application to take advantage of implicit trusted
connections as long as the application connects through DB2 Connect.
An explicit trusted connection grants temporary role privileges to the user the same way that an implicit trusted connection does. In addition, an explicit trusted connection lets you change the authorization ID used when performing actions across that connection. Changing the authorization ID on an explicit trusted connection is referred to as switching users. The authorization IDs to which you can switch and whether a given authorization ID requires a password when switching to it are defined as part of the trusted context that allowed the trusted connection to be created.
User switching can significantly reduce the processing usage of sharing a connection among several users, especially for user names that do not require a password because in that case the database server does not authenticate the authorization ID. When using the feature, however, you must be very certain that your application does not allow switching to an authorization ID without
validating and authenticating that authorization ID. Otherwise you are creating a security hole in your system.
Explicit trusted connections can be created and the user can be switched when connecting through DB2 Connect using CLI or JDBC, including XA established connections. Creating an explicit trusted connection and switching users requires setting special connection attributes. This means that existing applications will need to be modified in order to take advantage of explicit trusted connections.
Other than the differences just mentioned, you can use a trusted connection (whether implicit or explicit) the same way you would used a regular connection.
You must be certain, however, to explicitly disconnect an explicit trusted connection when you are done with it, even if it is in a broken or disconnected state. Otherwise resources used by the connection might not be released. This is not a problem with implicit trusted connections.
Note:
1. Explicit trusted connections should not use CLIENT authentication. This does not apply to implicit trusted connections.
2. Applications using explicit trusted connections should be run on secure machines which are password protected and accessible only to authorized personnel. This does not apply to implicit trusted connections.