OpenEdge Data Management: DataServer for Microsoft SQL Server

Data source record locking
to be lost because the procedure applies updates based on the first find of the record, and these
updates will overwrite the values from the second find of the record.
Using the DataServer to access a MS SQL Server database ensures that locks are upgraded in
the data source in the same way as in an OpenEdge database. For example, the following
procedure causes the same behavior whether you access an OpenEdge database or a MS SQL
Server data source:
FIND customer WHERE customer.custnum EQ 10.
DISPLAY customer.
PROMPT-FOR customer.
DO TRANSACTION:
ASSIGN customer.
END.
The record is share-locked when it is fetched. The DataServer upgrades the share lock to an
exclusive lock inside the transaction by locking the record, reading it, and checking whether the
record has changed since it was first fetched. If it has changed, the lock upgrade fails and you
receive an error message.
You might have to wait to access a record under the following circumstances:
• You try to update a record when another user is reading it (it is share-locked). This also
depends on the isolation level.
• You try to read or update a record when another user is updating it (it is exclusive-locked).
When this happens, OpenEdge uses a time-out loop, checking periodically to see whether the
record is available. You can choose Cancel at any time to abort the request.
The MS SQL Server data source notifies the DataServer if it cannot perform a requested
operation within a given period of time. Under unusual system or network loads, the DataServer
might receive notification that a request has not been completed. In this case, it returns a
message that the record the request was accessing is locked, even though no other user has a
lock on the record.
One type of locking behavior that you might encounter is a deadlock, or “deadly embrace.” A
deadlock occurs when two users want to access each other’s table, page, or record, and the table,
page, or record that they want either has an exclusive lock on it, or one of the users needs to put
an exclusive lock on it. Neither table, page, or record will give up its lock until the other table,
page, or record is available. When a MS SQL Server data source detects this situation:
• The data source kills the transaction that has accumulated the least amount of CPU time
and releases the table, page, or record for the other user.
• The ABL displays a message that the transaction was killed.
• The system responds as if you had chosen Cancel.
For details on how OpenEdge database locks work, see OpenEdge Getting Started: ABL
Essentials. See ODBC and MS SQL Server documentation for more information about locks in
MS SQL Server.
2–41