We have had similar client side errors on heavily worked Windows NT WS, no
errors on the server and reboot of the client fixes it. These are very long
running routines that pump data from a to b. Never actually found out what
the problem is, but never corrupts the server and only happens once in a
blue moon.


On the index side, because indexes are backed up as commands, not data, I
can't see how a corruption can migrate through the backup / restore cycle.

Does the server ever:
crash other times
get taken down by administrators forceably when it is in the middle of
"thinking". We got index errors when we downed servers that were at 100%
for hours.


""mgastde"" <michael.gast@...> wrote in message
news:ab7s9e+5rd6@......

> Hi,
>
> we have very strange errors in one of our customers production
> environment.
>
> We are using Firebird CS 1.0.0 Build 796 on a cluster system with
> RedHat
> Linux 7.2.
>
> About 7 weeks weeks ago we started with a brand new implemented
> production control system. After 5 weeks of work without any trouble,
> we
> started to get problems with the system. We have got messages in our
> application like
> "database file appears corrupt () wrong page type
> page XXX is of wrong type (expected 7, found 0)"
> "database file appears corrupt () wrong page type
> page YYY is of wrong type (expected 5, found 0)"
> These errors are NOT written to the interbase.log file. They arise
> only
> in our applications. If we start same the transaction a second time,
> the
> error usually does not occur again, but sometimes it does. At this
> point
> we started gfix -v -f to examine the database. It reported us a lot of
> messages like "Index 3 is corrupt on page 299129 in table FSATZ
> (159)".
>