If transaction and rollback logging were set up in the Console/Transaction Logging option in DFSETUP, a program updates the database in three stages:
Post or Kill
Each new or amended record is posted to a buffer and each deleted record is flagged as "killed". The buffer is usually a workfile with the extension .$$$ on disk. In a system crash changes that have been posted but not committed or secured are lost.
Commit
The records in the post buffer are checked. If the commit is successful, the records are written to the transaction log and database buffers in memory. The roll-back log buffer is updated with the "before image" of the record. Buffers are written to disk when the space is required for other purposes. In a system crash the last few committed transactions may be lost.
Secure changes
This stage secures the updates made by your program. The transaction log and rollback buffers are flushed to disk. In a system crash the rollback log can be used to restore the database to its state before the crash and the transaction log re-applies the transactions to the database. If the database is corrupted, the transaction log can be applied to an earlier version of the database to recover the changes made so far. See Securing changes for more information.
If you do not set up your program to use the Private Database facility, QA Build performs these actions at the following points in your program:
Post or Kill
Records are posted during the execution of a procedure body, when all the fields for a record have been processed
Commit
A commit occurs at the end of the procedure body, before any subsidiary procedures are executed. Records are checked using the validation set up for the database and using the validation mode in the table processing for the procedure body (see Table Processing, Related Table Processing and Additional Table Processing). For batch procedures, you can control the frequency at which records are committed by changing the value of the standard variable commit_frequency. Used carefully, this feature may give you a performance improvement
Changes are secured at the end of a procedure that sets the Secure changes flag in the Procedure Body Overview. For procedures with subsidiary procedures, the subsidiaries are executed before the changes are secured. If you do set up your program to use the Private Database, records are posted as above, but they are only committed and secured when a procedure body set up to Secure changes is executed. This means that a large number of changes can be stored and then saved or abandoned in one logical transaction. For further information see Private Database.
Whether or not you use the Private Database, you can prevent changes from being committed or secured at a specific point in your program by modifying the standard variable abandon_changes (or decommit).