At 08:06 AM 17/02/2004 -0500, you wrote:

>I'm researching another error in the database that showed up in last nights
>backup log (wrong page type - expected 7, found 5). I found an entry from
>November of last year, where Ann Harrison says:
>
> >gbak: writing data for table RUC
> >gbak: ERROR: database file appears corrupt ()
> >gbak: ERROR: wrong page type
> >gbak: ERROR: page 163478 is of wrong type (expected 7, found 5)
> >gbak: ERROR: gds_$start_request failed
> >gbak: Exiting before completion due to errors
> >
>Page type 7 is an index page. Page type 5 is a data page. Errors like
>(expected 7, found 5) are much nicer than the alternative (expected 5,
>found 7). Indexes can be ignored and recreated. A data page that's
>lost is gone.
>
>
>In this case, I can see by the verbose entries in the backup log which
>table failed. I did an alter index inactive / alter index active on the
>two indices on this table, and running another backup now to see if that
>fixed the problem.
>
>I noticed the same type of entries in the Firebird log. However, they have
>no context as to which table the problem belongs to, just the page
>number. Is there some way to tell from the entries in the log just what
>table(s) may have a problem? I noticed two different contiguous sets of
>page numbers, and am now wondering if there were two different tables
>affected.

No, it's quite normal for data from a table to be spread over different
blocks of disk.

/hb