internal gds software consistency check (cannot find tip page (165))

By: Quinn Wildman

Abstract: This error can occur on a read only database after many transactions

Background:

InterBase 6.0 introduced the concept of read only databases. Here is information on how to make a database read only from page 6-8 of the InterBase 7.0 Operations Guide manual:

To change the mode of a database between read-write and read-only, you must be either its owner or SYSDBA and you must have exclusive access to a database. From within InterBase, you can change a read-write database to read-only mode in any of three ways:

  • In IBConsole, select the database, display its properties, and edit the mode.
  • Use gbak to back up the database and restore it in read-only mode:

    gbak -create -mode read_only foo.ibk foo.ib

  • Use gfix to change the mode to read-only:

    gfix -mode read_only foo.ib

The problem:

It has recently been discovered that creating many transactions for one connection to a read only database can generate the error "internal gds software consistency check (cannot find tip page (165))" or "internal gds software consistency check (can't continue after bugcheck)". Under this condition the database is not corrupted.

Potential workarounds to this problem:

  • Disconnect and reconnect to the database before the error occurs.
  • Make the database read write.
  • If you Back up and Restore the database the error will probably not occur on the restored database.
This error has been reproduced against InterBase 7.1. While Borland has not tested it against older version of InterBase, we believe it to be in all versions of InterBase since 6.0. Borland is actively investigating the problem and intends to fix this problem in the first InterBase version to be released after Interbase 7.1.

The error "internal gds software consistency check (cannot find tip page (165))" can also indicate a corrupted database. Under most conditions when this error occurs you cannot connect to the database using any tool. To attempt to resolve this problem first mend the database:

gfix -mend db_name

Next, make the database read only as shown above. Finally, backup and restore the database:

gbak db_name backup_name
gbak -c backup_name new_db_name

If these steps do not work your best option is to use your backup that was created before the database become corrupted. If you do not have a backup, Borland recommends Devrace to attempt to repair your database.

Server Response from: ETNASC04