OpenEdge Data Management: DataServer for Microsoft SQL Server

Chapter 2: Initial Programming Considerations
Transactions
With DataServer operations, a MS SQL Server data source handles its own transaction
roll back and recovery operations. However, the OpenEdge transaction scoping rules
apply: a transaction ends when the code exits the outermost block that performs an
update. With the DataServer, ABL performs as follows:
• Sends a COMMIT to the data source, when a transaction that updates a MS SQL
Server data source ends successfully.c
• Sends a ROLLBACK to the data source if you interrupt the transaction.
See OpenEdge Getting Started: ABL Essentials for details on how ABL handles
transactions and error conditions.
Transaction scoping and buffer management
The DataServer and an OpenEdge database hold locks differently at transaction
boundaries. The OpenEdge database will hold a lock past the transaction boundary
where the DataServer will not. This causes different behavior in the use of buffers.
Consider the following example:
DEFINE BUFFER st_buf1 FOR state.
DEFINE BUFFER st_buf2 FOR state.
DO TRANSACTION: /* Transaction 1 */
FIND st_buf1 WHERE st_buf1.state EQ "NH" EXCLUSIVE-LOCK.
DISPLAY st_buf1.state-name. /* state-name = "New Hampshire" */
END.
/* During this pause, state-name is changed from "New Hampshire" to "Granite
State" by an external user */
PAUSE MESSAGE " state.state-name ".
DO TRANSACTION: /* Transaction 2 */
FIND st_buf2 WHERE st_buf2.state EQ "NH" EXCLUSIVE-LOCK.
DISPLAY st_buf1.state-name st_buf2.state-name.
END.
Executing the above code against an OpenEdge database will downgrade the
EXCLUSIVE-LOCK in Transaction 1 to a SHARE-LOCK. This occurs at the end of
Transaction 1 and remains in effect at the time of the PAUSE statement and prior to the
start of Transaction 2. This SHARE-LOCK prevents another user from modifying the
state-name value between the transactions. As an optimization, when Transaction 2
is executed, the client does not refresh the st_buf1 buffer since the SHARE-LOCK
prevented its contents from becoming stale between transactions. Also, since st_buf2
will have the same data integrity as st_buf1, they share the same buffer content.
Executing the above code against the DataServer will have different results because
the DataServer does not retain any lock conditions beyond the scope of the transaction
boundary. The DataServer will release the EXCLUSIVE-LOCK on the record at the END
statement of Transaction 1. This leaves the record exposed to modification by another
client during the PAUSE statement. If another client modifies the state-name value to
“Granite State” during the PAUSE, Transaction 2 will read the updated value during the
FIND statement. However, because of OpenEdge buffering rules and record scoping,
neither buffer is refreshed with the updated value and the DISPLAY statement displays
“New Hampshire New Hampshire.”
100 OpenEdge Data Management: DataServer for Microsoft SQL Server