Subject RE: [firebird-support] Database corruption
Author Helen Borrie
At 10:23 PM 5/09/2004 -0400, you wrote:
> > >
> > >I have heard that it is not possible to corrupt a Firebird database
> > >with forced writes on, but I have here an example of it occurring.
> >
> > That's a myth. it only avoids one source of corruption. I
> > can tell you six other ways to corrupt a Firebird database.
> > That's without going into the possibilities in the cases
> > where old databases have been hooked up to new server
> > versions... (dialect differences, ODS differences...)
>Hmm, I believe that one was from queen Ann herself.

Then I'm sure you misinterpreted her. But I hope Ann will comment...

>We did a backup/restore on the db when moving to the latest version of FB.
>It has remained a dialect 1 db.

Was this recent? Could you run a gstat -h just to make sure about the ODS

The error reported by gbak:
"database file appears corrupt ()
-wrong page type
-page 1653541 is of wrong type (expected 7, found 5)"

indicates a corrupt (possibly empty) index page. If you can find out which
index it was for, and it is a user index, probably dropping the index will
fix the problem. I've done this successfully on a database that got this
sort of corruption from the building's power being hit by an electrical storm.

If you don't have it, get hold of the IBSurgeon viewer (
and connect from it to your database, to see what you can find out about
this index.

For Alan McDonald's benefit, the reason I mentioned a Dialect 1 database
and ODS issues is that dbs built with (or restored under) Fb 1.5 have
indexes on system tables. I can't imagine why Alan thinks this issue has
anything to do with "connecting"...

>This is a completely different server from that one. I'll have the techs on
>site run a scan just to be sure though.


> > Classic on Windows is even vulnerable to the path string bug,
> > so beware of users who install third-party Admin tools and
> > use them to mess around with data and metadata. The only sure
> > way to get past this is to configure DatabaseAccess to None
> > and enforce the use of aliases.
>We have the environment locked down pretty well. All normal access to the
>db is thru a middle-tier application, or thru IIS via ODBC. Only two users
>(myself and one other - for read-only ad-hoc queries) have direct access,
>which is done via Alias (by convention rather than configuration, but that's
>a good idea).

I wasn't suggesting that users under controlled conditions would have been
responsible for it. But if it's not sufficiently locked down to prevent Mr
or Ms Gung-ho using a downloaded tool to play about with the database - as
could be the case if you have left DatabaseAccess unconfigured - then you
have a potential source of corruption.

>The only thing I can see from your post that I can do is a disk scan to rule
>out hardware issues. Might there be any other suggestions?

Include flaky network cards and cables among the hardware issues. Sorry to
harp on about this one (as I do from time to time). You should treat
network cards and cables as consumables, IMO. NICs are exposed to the air,
cables can get damaged, etc.,etc. I have a box here that I just use to run
an Apache server for intranet use. I only need to bump the desk to make
the cable fall out of the NIC. (Yes, it is a box built from
"leftovers":; its network name is "rusty", for good reasons!)