Firebird and InterBase Errors and Problems

Below is a description of the common errors and problems you can sometimes run into with Firebird and InterBase databases along with an approximate amount of time that would be required to fix them. Past experience indicates that this is the rough amount of time needed, and also the fact that we can most probably recover your data in a reasonable period of time.

These notes can help you to estimate the possible cost of using our database recovery services. Should you require our services to recover a database that has a problem, the cost for doing such work is as follows: $1250.00/5 hours, 5 hours minimum. Then $150.00 per hour until the repair is completed.

The possible reasons geting the errors detailed below are based on our experience and knowledge, however we cannot guarentee that you haven't found a new bug or problem that we are not familiar with.

Major Errors

  • Internal gds software consistency check (cannot find tip page (165))

    The required Transaction Inventory Page is corrupt and the database cannot be opened. It is expected in this instance that neither gbak nor gfix will be able to repair your database (except in the case of a Read Only database).

    Recovery Process:

    Analysis of lost and damaged data pages, generation of new transaction inventory pages instead of the lost and damaged ones, then a database check followed by a test backupand restore.

    Time: 2 hours+.
    Probable % of recovered data: 99%.

  • Database file appears corrupt. Wrong page type. Page NNN is of wrong type (expected X, found Y).

    This error can indicate a number of problems. But typically there are missing pages in the database, or the page that is being accessed is not the expected page type. For example, if the expected page type is 5, it can mean that some data may have been corrupted within a table. Such a corruption may prevent a sucessful backup backup or may make the table unavailable to the database.

    Recovery Process:

    Analysis of sequence of pages in the database, correction of invalid links in the sequence, possible regeneration of corrupted pages and generation of new ones. Then a data check by gfix followed by a final backup/restore.

    Time: 4-6 hours.
    Probable % of saved data: 50-100%.

  • Unknown database I/O error for file "*.gdb". Error while trying to read from file.

    The Database cannot be opened. This usually indicates that a number of database pages have probably been lost at the end of the database file. (power failure?). The database server cannot recreate a claid database from its own internal view. In this instance the database cannot be opened. Gfix cannot repair this.

    Recovery Process:

    Get the lost references to pages, their types and number by reading the non-corrupted pages. Then Generate new pages instead of the lost ones. Check the using gfix and then a backup/restore.

    Time: 3-5 hours.
    Probable % of saved data: 80%-95%.

  • Decompression overran buffer

    e.g. gds software consistency check (decompression overran buffer (179)).

    Can be a serious database corruption and and system tables can be damaged. Sometimes this error occurs after a database is transfered from one edian type of operating system to another using file copy rather than transportable backup. It is necessary to study each case.

    Recovery Process:

    Analysis of database links, generation of new pages, iterative repairs.

    Time: 3 hours and more.
    Probable % of saved data: 80%-90%.

  • Wrong record length e.g. gds software consistency check. Wrong record length.

    Some records are corrupted. The could be records from user tables or from the system tables (less likely).

    Recovery process:

    Usually it is possible to locate the wrong records and then delete them. Analysis of database, remove wrong links, iterative repairs.

    Time: 3 hours and more.
    Probable % of saved data: 60%-90%.

  • Database file appears corrupt. Bad checksum. Or Checksum error on database page XX.

    Caused by physical corruption. Depending on the page number the case can be either similar to problem 2 or very complex.

    Recovery process:

    Analysis of the problem page depending on its type and then restore of lost links.

    Time: 3 hours and more.
    Probable % of saved data: 99%.

  • Cannot find record back version

    The database seems to be ok, but gbak cannot backup properly and gfix does not solve the problem. The error is like: Internal gds software consistency check (cannot find record back version (291)) gds_$receive failed. Exiting before completion due to errors. internal gds software consistency check (can't continue after bug check). This a serious corruption and it can be very difficult to find the cause. It can be corrupted that could be due to physical database corruption, server code errors and rare combinations of metadata structures.

    Recovery process:

    The database requires a thorough analysis, and usually the solution is to find and delete the problem database objects and then recreate them. Sometimes it is necessary to transfer the data into a new database.

    Time: 4 hours and more.
    Probable % of saved data: 85%-99%.

  • Next transaction older than oldest active transaction

    e.g. Internal gds software consistency check (next transaction older than oldest active transaction (266)). This error occurs only on InterBase V4.x - V5.x because of the corruption of the header page.

    Recovery process:

    Usually it is necessary to set the appropriate transaction numbers on the database header page. Transaction numbers are counted after analyzing the records on the data pages.

    Time: 2-3 hours.
    Probable % of saved data: 99.99%.

  • Corrupted header page (at least)

    Database (of size less than 4Gb) cannot be opened and InterBase does not consider it as a database. At least the header page is corrupted, and the database will need a thorough investigation.

    Recovery process:

    Regeneration of the database system pages on the basis of whats there. This process is very difficult and we cannot be sure that we will get 100% success.

    Time: 4 hours and more.
    Probable % of saved data: difficult to say without analysis.

  • Database file size exceeds implementation limit

    The database size is 4Gb, and on InterBase V4.x, V5.x, V6.0.x, and early Firebird 0.9.x versions the database cannot be opened.

    Recovery process:

    Recovery consists of generating new system pages after analyzing the structure of the rest of the database and the manual correction of page links. This iteration process is very long but it is usually successful as most often database corruptions occupy only a small area.

    Time: 6 hours and more.
    Probable % of saved data: Usually we can save all the data (100%).

  • Conversion error from string

    During database restore there are the following error messages: "Conversion error from string "XXX". The error might be connected either with NULL's appearing in NOT NULL fields or by backup file corruptions, etc. Each time it is necessary to investigate the database in order to find the problem. Preliminary diagnosis is impossible.

    Recovery process:

    Analysis of the database data in order to see if there are any lost pages and if necessary transfer the data to a new database to find the problem areas. This process is iterative and time consuming.

    Time: 5 hours and more.
    Probable % of saved data: 80%+.

  • INET/inet_error: read errno = 10054 or 10038 or 10093

    Multiple entries in interbase.log or firebird.log with errors 10054, 10038, 10093, etc. These errors are caused by network problems - check your hubs, network adapters, etc. It is not an InterBase or Firebird error in itself, but it may cause problems.

    Recovery process:

    In this case it will be technical support, not a recovery process. If you have this problem and cannot solve it, you can request our support services.

    Time: 4 hours and more.
    Probable % of saved data: 100%.

  • Partner index description not found (175)

    internal gds software consistency check (partner index description not found. Missing index for a primary or a foreign key. The problem may be caused by physical database corruption or by a bug.

    Recovery process:

    To find the missing index, use following SELECT statement:

    select R.RDB$CONSTRAINT_NAME, R.RDB$INDEX_NAME as REFINDEXNAME,
   I.RDB$INDEX_NAME as REALINDEX, I.RDB$RELATION_NAME, I.RDB$INDEX_INACTIVE
from RDB$INDICES I RIGHT
    JOIN RDB$RELATION_CONSTRAINTS R on I.RDB$INDEX_NAME = R.RDB$INDEX_NAME
where R.RDB$CONSTRAINT_TYPE = 'FOREIGN KEY'
   or R.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY'
order by R.RDB$CONSTRAINT_NAME

    The contraint that is missing an index (where column REALINDEX is empty) will be corrupted. Try and recreate this constraint.

    If you need help to solve this problem, you may request our support services.

    Time: 2 hours and more.
    Probable % of saved data: 100%.

Other Errors

Error Messages Below are listed some InterBase/Firebird errors which can be caused for different reasons. Feel free to send us a description of your problem. We can help.

A problematic UDF is likely to generate the following errors in the interbase.log or firebird.log file.

SCH_validate -- not entered
SCH_validate -- wrong thread

Index corruption can cause the following errors in interbase.log or firebird.log file. Page 34672 is an orphan

This error can occur during intensive inserts/update/delete during a single transaction.

internal gds software consistency check (Too many savepoints (287))