CONNECT statement 
A CONNECT statement opens a
database session and a transaction for a database user.
Syntax
<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 <parameter_name> [<connect_option>...]
<connect_option> ::=
SQLMODE <INTERNAL | ANSI | DB2 | ORACLE>
| ISOLATION LEVEL <unsigned_integer> | TIMEOUT <unsigned_integer>
| TERMCHAR SET <termchar_set_name>
parameter_name, password, user_name, unsigned_integer, termchar_set_name
Explanation
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 opened implicitly (see
transactions). The COMMIT statement or ROLLBACK statement ends a transaction and opens a new one implicitly. At the end of each transaction, all locks assigned to the transaction are released, providing they are not maintained by a KEEP LOCK. The isolation specification in the connect statement is applied to each new transaction.
Each connect option may only be specified once.
SQL mode
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.
Locks / ISOLATION LEVEL
The unsigned integer after ISOLATION LEVEL keywords may only have the values 0, 1, 2, 3, 10, 15, 20, and 30.
Locks (see
transactions) can be requested either implicitly or explicitly. Explicit lock requests are made with the LOCK statement. The specified isolation level determines whether a lock is requested implicitly or explicitly. The length of time for which an implicit SHARE lock is maintained also depends on the isolation level. Exclusive locks set implicitly cannot be released within a transaction. Explicit lock requests are possible with every isolation level.
- ISOLATION LEVEL 0
: rows can be read without requesting SHARE locks; i.e. no SHARE locks are requested implicitly. For this reason, there is no guarantee that a given row will still be in the same state when it is read again within the same transaction as when it was accessed earlier, since it may have been modified in the meantime by a concurrent transaction.
Furthermore, there is no guarantee that the state of a read row has already been recorded in the database using COMMIT WORK.
When rows are inserted, updated or deleted, implicit exclusive locks are assigned to the transaction for the rows concerned. These cannot be released until the end of the transaction.
- ISOLATION LEVEL 1 or 10
: a SHARE lock is assigned to the transaction for each read row R1 in a table. When the next row R2 in the same table is read, the lock on R is released and a SHARE lock is assigned to the transaction for the row R2.
For data retrieval using a
QUERY statement, the database system ensures that, at the time each row is read, no exclusive lock has been assigned to other transactions for the given row. It is impossible to predict, however, whether a query statement causes a SHARE lock for a row of the specified table or not and for which row this may occur.
When rows are inserted, updated or deleted, implicit exclusive locks are assigned to the transaction for the rows concerned. These cannot be released until the end of the transaction.
ISOLATION LEVEL 15: for all SQL statements that read exactly one table row using the key, ISOLATION LEVEL 15 is equivalent to ISOLATION LEVEL 1 or 10.
With all other SQL statements, the description of ISOLATION LEVEL 1 also applies to ISOLATION LEVEL 15, with the exception that a SHARE lock is set for all the tables addressed by the SQL statement before they are processed. When the sql statement generates a result table that is not physically stored, these locks are not released until the end of the transaction or until the result table is closed. Otherwise, they are released immediately after the sql statement has been processed.
When rows are inserted, updated or deleted, implicit exclusive locks are assigned to the transaction for the rows concerned. These cannot be released until the end of the transaction.
ISOLATION LEVEL 2 or 20: all the tables addressed by the sql statement are locked in SHARE mode prior to processing. When the sql statement generates a result table that is not physically stored, these locks are not released until the end of the transaction or until the result table is closed. Otherwise, they are released immediately after the sql statement has been processed. This table SHARE lock is not assigned to the transaction with SQL statements in which just one table row is processed that is determined by key specifications or by CURRENT OF <result_table_name>.
In addition, an implicit SHARE lock is assigned to the transaction for each row read while an sql statement is being processed. These SHARE locks can only be released with the UNLOCK statement or by ending the transaction.
When rows are inserted, updated or deleted, implicit exclusive locks are assigned to the transaction for the rows concerned. These cannot be released until the end of the transaction.
ISOLATION LEVEL 3 or 30: an implicit table SHARE lock is assigned to the transaction for each table addressed by an sql statement. These table SHARE locks cannot be released until the end of the transaction. This table SHARE lock is not assigned to the transaction with SQL statements in which just one table row is processed that is determined by key specifications or by CURRENT OF <result_table_name>.
When rows are inserted, updated or deleted, implicit exclusive locks are assigned to the transaction for the rows concerned. These cannot be released until the end of the transaction.
The default isolation level is ISOLATION LEVEL 1.
The selected isolation level affects both the degree of concurrency and the guaranteed consistency. A high degree of concurrency is characterized by a state in which a maximum number of concurrent transactions can process a database without long waiting periods for locks to be released. As far as consistency is concerned, various phenomena can arise through concurrent access to the same database:
- Phenomenon 1: Dirty Read Phenomenon
A row is modified in the course of a transaction T1, and a transaction T2 reads this row before T1 has been concluded with a commit statement. T1 then executes the rollback statement, i.e. T2 has read a row that never actually existed.
- Phenomenon 2: Non-Repeatable Read Phenomenon
A transaction T1 reads a row. A transaction T2 then modifies or deletes this row, concluding with the commit statement. If T1 subsequently reads the row again, it either receives the modified row or a message indicating that the row no longer exists.
- Phenomenon 3: Phantom Phenomenon
A transaction T1 executes an SQL statement S that reads a set M of rows that fulfill a
search condition. A transaction T2 then uses the insert statement or the update statement to create at least one additional row that satisfies the search condition. If S is subsequently re-executed within T1, the set of read rows will differ from M.
The following table indicates the phenomena that can occur with each isolation level:

The lower the value of the isolation level, the higher the degree of concurrency and the lower the guaranteed consistency. This means that a compromise between concurrency and consistency that best suits the requirements of the application at hand must always be found.
TIMEOUT
The TIMEOUT value defines the maximum period of inactivity during a database session. The inactivity period is the time interval between the completion of an SQL statement and the next SQL statement. The session is terminated with a ROLLBACK WORK RELEASE when the specified maximum inactivity period is exceeded.
TIMEOUT values are specified in seconds. The specified TIMEOUT value must be less than or equal to the defined maximum TIMEOUT value.
- A TIMEOUT value created for a user is always a maximum TIMEOUT value.
- A TIMEOUT value defined for a usergroup is the maximum TIMEOUT value for all of the members of this group.
- For all other users, the installation parameter SESSION_TIMEOUT represents the maximum TIMEOUT value.
If no TIMEOUT value is specified, the database uses the maximum TIMEOUT value or the SESSION_TIMEOUT value, depending on which is smaller. The SESSION_TIMEOUT value is determined when the database system is installed.
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 with the NOT EXCLUSIVE attribute
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 usergroup 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.
TERMCHAR SET
Terminal character set name
User Manual: SAP DB ®
Definition of Terms ®
Language Support (Termchar Sets