OpenEdge Data Management: DataServer for Microsoft SQL Server

Initial Programming Considerations
2–40
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.
This example illustrates how OpenEdge and MS SQL Server data source share locks differ in
scope and duration:
FIND customer WHERE customer.custnum EQ 10 SHARE-LOCK NO-WAIT NO-ERROR.
IF AVAILABLE customer THEN DO:
DISPLAY customer.
PROMPT-FOR customer.
tx:
DO TRANSACTION ON ERROR UNDO tx, RETRY tx:
FIND customer WHERE customer.custnum EQ 10
EXCLUSIVE-LOCK NO-WAIT NO-ERROR.
IF LOCKED customer THEN DO:
MESSAGE "customer locked - retrying".
UNDO tx, RETRY tx.
END.
ELSE
ASSIGN customer.
END.
END.
In this example, the first record is only share-locked within the MS SQL Server data source if
the isolation level setting requires it. (Recall that a SHARE–LOCK specified in an ABL statement
is ignored by the DataServer.) As a result, if the isolation level is read uncommitted or read
committed, the record might be updated by another client before the second FIND statement
executes. This could cause the record that the second FIND statement fetches to be different from
the record fetched by the first FIND statement. This procedure might cause updated information