Kbase P30456: 4GL/ABL: How can I know what order the write triggers will be fired for distinct files?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/27/2010 |
|
Status: Verified
GOAL:
4GL/ABL: How can I know what order the write triggers will be fired for distinct files?
GOAL:
Which trigger fires when, when records from different tables are written to the database?
GOAL:
Is there any way to determine what order Progress executes write triggers for different tables within the same transaction?
FACT(s) (Environment):
Progress 8.x
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
FIX:
The order of firing write triggers depends on the order in which the actual writes to the database take place during processing.
A record is written to the database when:
1. It is forced by the RELEASE or VALIDATE statement.
2. It goes out of scope because no more buffers refer to it after it was updated. (Meaning: all buffers in the session that held the record now point to different records.)
3. The transaction in which the update takes place ends normally. (Meaning: It is not undone).
The automatic release of records (condition 2 and 3 above) can be unpredictable due to the interaction between record scope and transaction scope. Whichever ends first for a given record will cause the trigger to fire.
- If the buffer used in a transaction is the only buffer that holds records which are being updated, the WRITE triggers will fire in the same order as the updates. However, there is no real way to guarantee this, as it's always possible the transaction is started while another procedure or class also has a buffer pointing to the same record.
- If there is a buffer somewhere in the session outside of the transaction that also holds one of the records to be updated, the sequence breaks as the WRITE trigger for that record will not fire until the transaction ends (and it will not fire at all if the transaction is undone). This is the most common scenario that triggers questions on the order of WRITE trigger execution.
- If the same record is fetched in two or more buffers that are both repositioned during the transaction, things get really confusing as the write trigger for a record fires as soon as no buffers point to the updated record. In this case the order in which the WRITE triggers fire depends entirely on the program flow and the record set being updated.
The only way to control the order of execution of write triggers is to force the record writes explicitly by issuing RELEASE or VALIDATE statements in the code.