Maya

>
> It has happened at a few of our sites. We mostly pick it up at year end,
> since the system does not allow you to proceed to the new year, if it
> thinks there is an imbalance.

That's not good. Are you actually backing up and restoring on every
night, or was the original problem that when you found a problem,
you couldn't fix it overnight?

>
> We install Firebird 1.5.4 superserver by default (if there isn't already
> a copy of firebird installed) so most of these would have been 1.5.4
> superserver.
>
> We have moved the larger sites over to classic, and then some of them
> further onto Firebird 2.1.3
>
> So, it seems to be across all versions. We do not use Firebird 2.5, and
> we don't use the new monitoring tables (which has a known bug, of
> corrupting indexes)

It makes sense that it would be across versions, since the index code
is common to all - in theory there are few bugs in newer versions.

>
> I haven't managed to see a common denominator between all the sites
> experiencing this :-(

Are there any unusual characteristics of the bad indexes - e.g.
single key, compound, ascending/descending, unique? Key types -
character, number?

>
> It might be easiest though, if we just pick one site, and focus on that?

Have you got an example of a database with indexes that give
the wrong answers that you can send to a developer (Vlad does much
of the index work)? There's nothing like looking at the actual
problem...

>
> We have asked for the Firebird logs, and they all seem to contains a lot
> of entries like this:
>
>
> XYZAPPS Fri Mar 12 09:41:32 2010
> INET/inet_error: read errno = 10054

Unfortunately, those errors generally just mean that a program
ended without detaching from the database, leaving an open network
connection with nobody listening.

>

Best regards,

Ann