Logging and Rollback of File Update Operations

The record update operations WRITE, REWRITE, and DELETE can be rolled back. However, file operations which open, create, recreate, rename, delete, or close files cannot be rolled back. Therefore, OPEN, CLOSE, DELETE FILE, RENAME, and COPY operations cannot be rolled back.

When a transaction is committed, all of the file update operations are written to the default log file defined by the LOG-FILE configuration variable. However, if instead the transaction is rolled back, those file operations that cannot be rolled back are written to the default log file and then committed.

If a file that was opened during a transaction is closed outside of a transaction, the CLOSE will be treated as its own transaction and will be logged. If a file that has rollback enabled (using the WITH ROLLBACK syntax) is opened outside of a transaction, the OPEN is treated as its own transaction and will be logged. See Extended Locking Rules for more information.

If, during a transaction, a record is deleted from a file not allowing duplicates on a particular key, the delete may be rolled back only if the record key does not exist in the file at the time of the rollback.

This means that if another process writes a record with the same key to the file after the delete, then the delete will not be rolled back, and the rollback will fail with a duplicate key error. See Transaction Error Handling for more information.