Caveats

<< Version number | Firebird Database Housekeeping Utility | A. Document history >>

Shadows
Response codes are usually zero
Force closing a database
Limbo transactions
1. Limbo transaction options -
  all the same?
2. Limbo transactions - can be
  backed up

Caveats

This section summarises the various problems that you may encounter from time to time when using gfix. They have already been discussed above, or mentioned in passing, but are explained in more details here.

Shadows

The gstat seems to take some time to respond to the addition of shadow files to a database. After adding two shadows to a test database, gstat still showed that there was a Shadow count of zero.

Even worse, after killing the second shadow file and running the DROP SHADOW command in isql to remove the one remaining shadow file, gstat decided that there were now three shadow files in use.

Response codes are usually zero

Even using Firebird version 2 it appears that many commands, which fail to complete without an error, return a response of 0 to the operating system.

Note: This problem was fixed in Firebird 2.1 RC1. It has been tested and a successful operation returns zero to the shell while a failure returns 1. \\ This section will remain in the manual as there are still a large number of users with older versions of Firebird.

For example, the following shows two attempts to shut down the same database, the second one should fail - it displays an error message - but still returns a zero response to the operating system. This makes it impossible to built correctly error-trapped database shutdown scripts as you can never tell whether it actually worked or not.

 linux> gfix -shut -force 5 my_employee
 linux> echo $?
 0

 linux> gfix -shut -force 5 my_employee
 Target shutdown mode is invalid for database -
 "/home/norman/firebird/my_employee.fdb"
 linux> echo $?
 0

Note: As mentioned above, this is no longer a problem from release 2.1 RC1 onwards. The second attempt to close the database will correctly return 1 to the shell.

Force closing a database

Under classic server, using the -f[orce] option to the -shut command acts exactly the same as the -at[tach] option.

Limbo transactions

There are a couple of problems with limbo transactions as discovered by Paul in his testing.

Limbo transaction options - all the same?

When processing limbo transactions, it appears under Firebird 1.5 at least, that the -l[ist] -p[rompt] option is called regardless of whether you use -c[ommit], -r[ollback] or -t[wo_phase]. The outcome is the same regardless of whether the DBA specifies a specific transaction number or all on the command line - a prompt is given with the option to commit, rollback or neither.

Limbo transactions - can be backed up

Paul's testing of limbo transactions revealed that it is possible to make a backup of a database with limbo transactions. This backup can then be used to create a new database and the limbo transactions will still be able to be listed. This applies to a filesystem copy of the database and to version 1.5 of Firebird.

If you attempt to list the limbo transactions in the copy database and the original database has been deleted, renamed or has been set to read-only, then gfix will present you with a request to supply the correct path to the original database.

 linux>cd /home/norman/firebird
 linux>cp my_employee.fdb my_new_employee.fdb

 linux> mv my_employee.fdb my_old_employee.fdb

 linux> gfix -list /home/norman/firebird/my_new_employee.fdb
 Transaction 67 is in limbo.
 Could not reattach to database for transaction 67.
 Original path: /home/norman/firebird/my_employee.fdb

 Enter a valid path: /home/norman/firebird/my_old_employee.fdb

   Multidatabase transaction:
   Host Site: linux
   Transaction 67
 has been prepared.
   Remote Site: remote
   Database path: /opt/firebird/examples/testlimbo.fdb

In the above example, the original database my_employee.fdb was first of all copied using the operating system command cp to my_new_employee.fdb and then renamed to my_old_employee.fdb.

gfix was then run on the copy named my_new_employee.fdb and it noted the limbo transaction. However, it could not find the original database file as it had been renamed, so gfix prompted for the path to the original database file. When this was entered, gfix happily listed the details.

Warning: This implies that if you have a database with limbo transactions and you copy it using the operating system utilities and subsequently run gfix against the new database, it is possible to have gfix fix limbo transactions in the original database file and not in the one you think it is updating - the copy.

It is also a good warning about making copies of databases without using the correct tools for the job.