|Subject||RE: [firebird-support] Database corruption|
> -----Original Message-----Hmm, I believe that one was from queen Ann herself.
> 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...)
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, thoughThis is a completely different server from that one. I'll have the techs on
> > 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?
site run a scan just to be sure though.
> Classic on Windows is even vulnerable to the path string bug,We have the environment locked down pretty well. All normal access to the
> 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.
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 toThe only thing I can see from your post that I can do is a disk scan to rule
> find out why and where the corruption is occurring and close the hole.
out hardware issues. Might there be any other suggestions?