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
version?

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 (www.ibsurgeon.com)
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.

Yup.

> > 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!)

./heLen