OpenEdge Data Management: DataServer for Microsoft SQL Server

Share locks
Data source record locking
The default isolation level for the MS SQL Server DataServer is read uncommitted. At this
level, a SHARE-LOCK and NO-LOCK are identical from the perspective of the DataServer and the
MS SQL Server data source. The higher isolation levels will determine what kind of share locks
will take effect. In MS SQL Server, a repeatable read and serializable isolation level are
synonymous.
The MS SQL Server DataServer ignores ABL SHARE–LOCK option when used in ABL
statements. Instead, share locks are governed by the data source and the available ODBC
isolation levels. If you wish to change the share lock behavior, you may be able to do so by
changing the isolation level at connection time using the -Dsrv parameter.
When you read records with an ABL statement, regardless of whether you include the
SHARE–LOCK option, the MS SQL Server data source typically performs as follows:
• It puts some form of share lock on the record, page, or table if the ODBC isolation level is
anything other than read uncommitted. This occurs regardless of whether the share lock is
specified in an ABL statement.
• After the data source reads the record, it releases the share lock if the isolation level is read
uncommitted or read committed. It may hold share locks until the completion of a
transaction if the isolation level is repeatable read or serializable.
If you hold a record with a share lock, other users can usually access that record and apply a
share lock, but this is dependent on the isolation level they have selected. Refer to the
transaction and locking references in the Microsoft documentation that addresses ODBC
programming or data source reference manuals for more information.
Exclusive locks
When you update, delete, or create a record, MS SQL Server puts an exclusive lock on the
record; however, the data source does not apply the exclusive lock to a record until all share
locks on it are released. Therefore, you cannot perform an update on a record until other users
release it. If a record has an exclusive lock on it, no other user can access it until it is released
at the end of a transaction. In a OpenEdge transaction block, the data source always holds an
exclusive lock until the end of a transaction’s scope if the data source driver supports
commitment control boundaries and the ODBC AUTOCOMMIT feature is not turned on.
Handling lock timeouts
The default behavior for handling a lock timeout condition in the OpenEdge DataServers is to
return control immediately to the OpenEdge client. Therefore, the lock wait timeout at the data
source is set to zero at the beginning of a client session when using the OpenEdge DataServer
for MS SQL Server. This is desirable behavior for clients that want immediate control over lock
handling. The client application can choose to handle the lock timeout directly using the
NO-WAIT and NO-ERROR keywords. Then, when a record cannot be accessed because it is locked
by another user, the application can test for the server timeout condition by testing for TRUE
returned from the LOCKED function. The application consumes the timeout condition in this case
and is free to perform whatever action is deemed necessary.
2–37