> Yes this is probably a bug, and it will be hard to find since it's
> rare and hard to reproduce. If I had a copy of the database with
> the broken index, I might be able to figure out something...

Unfortunately, I cant give you the database as it contains plenty of
protected information! I am willing to spend time trying to get the
issue to reproduce on a test database though. Any ideas how?

> However, you don't need to do a full backup to fix this problem.
> The error tells you that the bad index is on the table ACTIONS, and
> it's index 19. If you look in RDB$INDICES for the indexes on the
> ACTIONS table, you'll find both index names and index ids. Deactivate
> and reactivate index 19 and the problem will be fixed.

I had a look and this index is a foreign key with low selectivity. I
then had a look at the firebird.log for a previous corruption and
found that 5 indexes on the same table were corrupt and all but 1 were
foreign keys with low selectivity.

>
> >
> > KSSHEPRFX Mon Oct 23 10:23:09 2006
> > Database: F:\CALLSYS\SHEFFIELD\LIVE\DB\CALLSYSSHEFLIVE.FDB
> > Relation has 1691 orphan backversions (1 in use) in table ACTIONS

(162)

>
> That's an error, but not a serious error. If the server is shutdown
> hard (e.g. crashes) there may be some incomplete garbage collection.
> When garbage collecting, Firebird first removes the pointer to the
> unneeded version from the next version, then removes the old version
> itself. Pointers to nothing are much worse that a few bytes of lost
> space.

Could I have caused this by doing a forced shutdown? in that case this
may have occured after the index corruption when I was trying to close
all the connections to the DB.


Regards,
Will.