--- In firebird-support@yahoogroups.com, "Bob Murdoch"
<mailgroups@...> wrote:

>
> I just experienced my semi-yearly database corruption on an FB 1.5
> 30GB database running on W2K3 server. I just finished running gfix,
> and have a number of entries in Firebird.log that look like this:
>
> Index 4 is corrupt on page 3853736 in table XRDS501 (303)
>
> From previous experience, I know that I can alter the index
> inactive/active to rebuild it. However, how do I know exactly which
> index is "Index 4"?
>
>
> tia,
>
> Bob M..

Corruption should never occur except by hardware failure, and if it
does, certainly not multiple times in a year.

Are forced writes on or off?
Has anyone used xcopy on the database?
Is there a backup tool that directly copies the fdb file?
Is there some virus scanner type tool that has access to the fdb file?
Have you run any memory checking tools to make sure you don't have a
hardware timebomb on your plate?

May be worth checking the release notes for 1.5.3 to see if any
serious bugs were fixed that may have caused it, but the only
corruption I have ever seen across over 300 customer sites can be
attributed to flaky hardware.

For future reference, it makes it a lot easier if you name your
primary keys, otherwise Firebird generates a pretty non-descriptive name.

eg:

CREATE TABLE FOO (
ID BIGINT NOT NULL,
BAR VARCHAR(200),
CONSTRAINT PK_FOO PRIMARY KEY (ID)
);

You can lookup the index in the system tables RDB$INDICES
(RDB$RELATION_NAME). RDB$INDEX_SEGMENTS will tell you which field(s)
the index is on, which should help you work out whether it is a
constraint or custom index.

If it is a constraint supporting index then you will need to drop and
re-add the constraint rather than the index itself.

Adam