FairCom DB V12 Release Notes

Automatic recovery and duplicate file IDs

If c-tree data or index files that are under full transaction control are copied and then accessed by the same FairCom Server that is accessing the original files, automatic recovery might apply changes to the wrong copy of the file.

FairCom Server stores a file ID that is used during normal operation and during automatic recovery. It is able to reassign the file ID of the copied file if the original file is open when the copied file is accessed. If the two copies of the file were not open at the same time, the duplicate file ID was not detected, which could cause automatic recovery to apply changes to the wrong file.

c-treeRTG includes a ctutil -fileid command to update the file ID of c-treeRTG files.

Note: Copying files is against FairCom’s recommended best practices. However, because copying files is fairly common in many industries, FairCom has the following provisions:

1. ctutil -filecopy and -copy options - Use the ctutil -filecopy and -copy options to copy files.
2. Restamp file ID after copying using the operating system - The ctfileid Update File ID utility (-fileid) is for restamping the file ID after a file is copied using the operating system facilities. It is located in tools\cmdline. See the Command-Line Tools documentation: ctfileid - Update File IDs.

Note: To avoid any further recovery issues with matching file IDs, FairCom strongly suggests educating your customer base to use option 1 to copy files or, after copying a file using option 2.

Automatic recovery handling of duplicate file IDs and transaction-dependent operations

In cases involving transaction-dependent file creates and renames, a duplicate file ID is caused by a system copy of a file, which could cause problems during automatic recovery. Symptoms included recovery failing with internal error 8777, or record counts being incorrect after automatic recovery, or possibly even an unhandled exception in very obscure situations. If automatic recovery opened the renamed file and the original file, their file IDs could conflict, causing internal error 8777. Or the redo of the create could cause the record count in the data file header to be reset to zero, or adjusted for operations on the copied or renamed file.

Automatic recovery has been modified to address this situation.

Improved detection of logically equivalent filenames during automatic recovery

Opening a file using a different, but logically equivalent path specification could prevent automatic recovery from determining that the file was part of a transaction-dependent rename operation. This could happen with two different physical files that have the same file ID. The filename check for transaction-dependent file operations has been improved so the logically equivalent path specifications are determined to be for the same file.