OpenEdge Data Management: DataServer for Microsoft SQL Server

Locking impact on queries
Data source record locking
The DataServer processes query statements marked with SHARE-LOCK and
EXCLUSIVE-LOCK queries very differently from NO-LOCK queries.
Note: There is an exception to the previous statement; queries marked SHARE-LOCK
when the record isolation level is read uncommitted are treated like a NO-LOCK.
The records of a NO-LOCK query are pre-fetched, which means that changes to the
result set after the query has been executed are unknown. Records modified in the
database after the query is established will not be reflected in the result set.
SHARE-LOCK and EXCLUSIVE-LOCK queries do not pre-fetch records, but do preselect
record keys. The query behavior is that of a “keyset-driven” cursor. Since the record
keys are stored at the time an ABL query is first executed, new records added to the
database since the key list was established are not included in the query result set.
However, records that have been deleted or modified in the database will be reflected
in the query results as records are accessed by the application.
Locking examples
The following example illustrates how the end of a transaction affects OpenEdge and
MS SQL Server data source locks differently:
DO TRANSACTION:
FIND customer WHERE customer.custnum EQ 10.
UPDATE customer.
END.
Note the following points:
• When you access an OpenEdge database with this procedure, the customer
record is share-locked when the first transaction ends.
• When you access a MS SQL Server data source with the DataServer, the
customer record is released when the first transaction ends.
OpenEdge Data Management: DataServer for Microsoft SQL Server 97