Progress
Programming
Handbook
Transactions and Triggers
If a transaction begins with a trigger, it cannot extend beyond the end of the trigger. If the transaction is scoped to a block within the trigger, the normal transaction scoping rules apply. If the trigger is scoped to the trigger block itself, the transaction ends when the trigger ends.
In the procedure
p-txn12.p
, a transaction occurs within the CHOOSE trigger for the upd–cust button and within the CHOOSE trigger for the del–cust button:
The transaction for updating a customer is scoped to the trigger block for CHOOSE of upd–cust. The transaction begins and ends when the trigger begins and ends. The transaction for deleting a customer is scoped to a DO block within the CHOOSE trigger for del–cust. The transaction begins and ends when the DO block begins and ends.
If a transaction is started in the main code and is active when a trigger is invoked, the trigger becomes part of the transaction. You cannot end the transaction within a trigger. For example, the procedure
p-txn13.p
begins a transaction for each pass through the DO WHILE loop (trans–loop) in the main code. All updates and deletions performed within the loop are part of a single transaction. When you choose either the tran–com or tran–undo button, the loop either iterates or is undone. At that point, all changes made during that iteration are either committed or backed out.
When you choose the exit–app button from the main screen, the DO WHILE loop completes and the last transaction is committed.
NOTE: Generally, you do not want transactions to span triggers. Instead, you should design your application so that each transaction occurs within a single trigger. Otherwise, undoing one action might cause other unrelated actions to be undone also.Transactions are, by nature, modal. This creates conflicts when you try to write a modeless application. You can handle this is one of two ways:
The procedure
p-txn14.p
allows what appears to be a modeless update:
When you run this procedure, focus is initially in the main–frame frame. When you move focus to the curr–frame, the ON ENTRY trigger applies an EXCLUSIVE–LOCK to the customer record. Subsequently, when you either choose the com–cust button or change the iteration of the browse, a small transaction assigns your changes to the customer record. The EXCLUSIVE–LOCK on the record is then released.
Although this example appears modeless when you run it, it is really modal. When you move focus to the curr–frame frame you enter a mode in which you hold an EXCLUSIVE–LOCK on the customer record (previously, you held the record NO–LOCK). This mode remains in effect until you choose either the com–cust or rev–cust button or change the iteration of the browse. At that point, the EXCLUSIVE–LOCK is released.
NOTE: While it is possible to present a modeless update, it requires somewhat complex coding for even a simple example, as inp-txn14.p
. In a more realistic example where the user has more choices of actions, this technique is more difficult and more dangerous. Using modal updates with dialog boxes is safer and is the preferred approach.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |