
A CONNECT statement opens a database session and a transaction for a database user.
<connect_statement> ::=
CONNECT <parameter_name> IDENTIFIED BY
<parameter_name> [<connect_option>...]
| CONNECT <parameter_name> IDENTIFIED BY <password>
[<connect_option>...]
| CONNECT <user_name> IDENTIFIED BY <parameter_name>
[<connect_option>...]
| CONNECT <user_name> IDENTIFIED BY <password>
[<connect_option>...]
<connect_option> ::=
SQLMODE <INTERNAL|ANSI|DB2|ORACLE>
| ISOLATION LEVEL <unsigned_integer>
| TIMEOUT <unsigned_integer>
parameter_name, password, user_name, unsigned_integer
If the parameter name/user name and parameter name/password combination is valid, the user opens a database session and gains access to the database. As a result, he or she is the current user in this session.
A transaction is implicitly opened.
Each connect option ( connect_option) may only be specified once.
The specification SQLMODE <INTERNAL|ANSI|DB2|ORACLE> can be used to select the SQL mode. The default SQL mode is INTERNAL.
The CONNECT option SQLMODE <INTERNAL|ANSI|DB2|ORACLE> is not allowed in programs. The appropriate precompiler option must be used to specify an SQLMODE other than INTERNAL.
The
isolation level
specified in the connect
statement is applied to each new transaction. This specification
determines the lock operation type (
Lock
Behavior).
The isolation level is set using an integer without a plus/minus sign after the keywords ISOLATION LEVEL. The following values are permissible: 0, 1, 2, 3, 10, 15, 20, and 30. If no isolation level is specified, isolation level 1 is used.
The specified
timeout value
must be smaller than or the same as the current timeout value, otherwise an
error is returned at logon.
If no timeout value is specified, the system uses the current timeout value.
If the TIMEOUT value is set to 0, the inactivity period is not monitored. This can result in a situation where database resources are not available again even though the associated application was concluded or aborted without a RELEASE statement.
Users defined with the attribute NOT EXCLUSIVE can open several sessions at the same time. Whenever this is the case, or whenever two users of the same user group open a session at the same time, the sessions are considered to be distinct. This means that lock requests of the sessions concerned can collide.