At 07:18 PM 27/08/2007, Hans wrote:

>In one of my databases I get this message (after a gfix):
>'Index 7 is corrupt on page 354716 in table...'
>Now in my (still existing) optimism I suppose this could be cured by
>dropping the index and recreating it. I can not find anything about
>this anywhere... Am I right here?
>
>And if this is the case, how do I find 'index 7'? Normally, indexes
>are referred to by names, constraints etc, is there a translation to
>these?

Umm, no, this is an example of riddle-me-ree.

From jrd/validation.cpp:
" For each index, the btree pages are fetched from top-down, left to
right.
Basic validation is made on non-leaf pages to ensure that each node
on page points to another index page. If -full validation is specified
then the lower level page is fetched to ensure it is starting index
entry is consistent with the parent entry.
On leaf pages, the records pointed to by the index pages are not
fetched, the keys are looked at to ensure they are in correct
ascending order.

If a visited page is not part of the specified relation and index,
the following error is returned:

"Index xxx is corrupt at page xxx"

I'm led to understand that these *internal* numbers are applied to
the indexes relative to each relation, such that the first index for
a table is Index 0 and the eighth one would be Index 7.

What I can't tell you is the order in which the group of indexes for
each relation is walked (and thus, numbered). That's where the
riddle begins. It might be alphabetical order or it might be
creation order (if that's different). Maybe gstat -i could give a
clue, in case there is actually some sort of coherence there.

As to the stupidity or otherwise of such a message emitting from a
utility that's meant to help you, you're welcome to judge for
yourself. If you tell me what version of Firebird you're using I'll
post a bug report in the tracker...or you could do it yourself if you prefer.

./heLen