> -----Original Message-----
> From: Helen Borrie [mailto:helebor@...]
> Sent: Sunday, September 05, 2004 9:17 PM
> >
> >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.

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

> > We also had a corrupt database in Jan or Feb of this year, though
> > that was with a beta of 1.5 super server on older server hardware
> > (though still forced writes and raid 5).
>
> Have you scanned the disks since then?

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

> Some kinds of corruption can't be cured with gfix.

Tell me about it. <g>

> But the primary objective in your current situation is to
> find out why and where the corruption is occurring and close the hole.

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?

tia,

Bob M..