The DISCONNECT statement ends one or more connections for unprotected conversations.
This statement can only be embedded in an application program or issued interactively. It is an executable statement that cannot be dynamically prepared. It must not be specified in Java™ or REXX.
DISCONNECT is not allowed in a trigger or function.
If a global variable is referenced in a statement, the privileges held by the authorization ID of the statement must include at least one of the following:
- For the global variable identified in the statement,
- The READ privilege on the global variable, and
- The system authority *EXECUTE on the library containing the global variable
- Database administrator authority
- server-name or variable
- Identifies the application
server by the specified server name or the server name contained in
the variable. It can be a global variable if it is qualified with
schema name. If a variable is specified:
- It must be a character-string variable.
- It must not be followed by an indicator variable
- The server name must be left-justified within the variable and must conform to the rules for forming an ordinary identifier
- If the length of the server name is less than the length of the variable, it must be padded on the right with blanks.
When the DISCONNECT statement is executed, the specified server name or server name contained in the variable must identify an existing dormant or current connection of the activation group. The identified connection cannot use a protected conversation.
- Identifies the current connection of the activation group. The activation group must be in the connected state. The current connection must not use a protected conversation.
- ALL or ALL SQL
- Identifies all existing connections of the activation group (local as well as remote connections). An error or warning does not occur if no connections exist when the statement is executed. None of the connections can use protected conversations.
DISCONNECT and CONNECT (Type 1): Using CONNECT (Type 1) semantics does not prevent using DISCONNECT.
Connection restrictions: An identified connection must not be a connection that was used to execute SQL statements during the current unit of work and must not be a connection for a protected conversation. To end connections on protected conversations, use the RELEASE statement. Local connections are never considered to be protected conversations.
The DISCONNECT statement should be executed immediately after a commit operation. If DISCONNECT is used to end the current connection, the next executed SQL statement must be CONNECT or SET CONNECTION.
ROLLBACK does not reconnect a connection that has been ended by DISCONNECT.
Successful disconnect: If the DISCONNECT statement is successful, each identified connection is ended. If the current connection is destroyed, the activation group is placed in the unconnected state.
DISCONNECT closes cursors, releases resources, and prevents further use of the connection.
DISCONNECT ALL ends the connection to the local application server. A connection is ended even though it has an open cursor defined with the WITH HOLD clause.
Unsuccessful disconnect: If the DISCONNECT statement is unsuccessful, the connection state of the activation group and the states of its connections are unchanged.
Resource considerations for remote connections: Resources are required to create and maintain remote connections. Thus, a remote connection that is not going to be reused should be ended as soon as possible and a remote connection that is going to be reused should not be destroyed.
Example 1: The connection to TOROLAB1 is no longer needed. The following statement is executed after a commit operation.
EXEC SQL DISCONNECT TOROLAB1;
Example 2: The current connection is no longer needed. The following statement is executed after a commit operation.
EXEC SQL DISCONNECT CURRENT;
Example 3: The existing connections are no longer needed. The following statement is executed after a commit operation.
EXEC SQL DISCONNECT ALL;