A CONNECT statement (connect_statement) opens a database session and a transaction for a database user.
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>...]
| SQLMODE ANSI
| SQLMODE DB2
| SQLMODE ORACLE
| ISOLATION LEVEL <unsigned_integer>
| TIMEOUT <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 instance. As a result, he or she becomes the current user for this database session.
A transaction is implicitly opened.
Each connect option (connect_option ) may only be specified once.
The specification SQLMODE <INTERNAL|ANSI|DB2|ORACLE> is used to select the SQL mode. The default SQL mode is INTERNAL.
The isolation level specified in the connect statement is applied to each new transaction. This specification determines the lock operation type.
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.
Concepts of the Database System, Isolation Level
The specified timeout value must be smaller than or equal to the database parameter SESSION_TIMEOUT, and the user-specific timeout value of the user or user group. If it is not, an error is displayed at logon.
If a timeout value is not specified, the smaller of the other two values is adopted as the 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 for the sessions concerned can collide.