Hi!

This is a new one for me: I have a Firebird 2.5 database file with
corruption not in records, but in table structures themselves. After I
used "GFIX -v -f", "GFIX -m" and backup/restore, I am left with a
database which basically works, but as soon as I try to access certain
tables, I get an "Internal Firebird consistency check (cannot find
record back version (291))"; from this time on, until I restart the
Firebird service, just about every access to the database file raises
the consistency error.

As luck would have it, the damaged tables are non-essential: As far as
useful data are concerned, I could drop the tables and create them again
and all would be fine. Except that I can't, because these tables have
triggers attached and as soon as I try to drop the triggers, I get the
consistency error.

Can anyone suggest a way to fix this database? The only solution that I
can think of involves creating a new database with the same structure
and moving data from all non-damaged tables to it. I am not too happy
with this solution, though, as moving that many records around would
take up some serious time.

Another question: As far as I was able to determine, this problem arose
when the user rebooted the server while database operations were
running. It's been my impression that transactions (with forced writes)
should pretty much prevent any problem with abuse of this kind, and even
if they couldn't, why would an unfortunate reboot damage several
unrelated tables, most of which were almost certainly not being used at
the time of the reboot?

Thanks,

Pepak