>
> I think I have finally lost the will to argue the case for Firebird.
> Repeated database corruption has cost my major client
> thousands of dollars in downtime.
>
> I have done everything possible;
> gbak & restore, correct client software etc. but every month
> or so the dreaded "internal gds software consistency check
> (can't continue after bugcheck)" message returns.

Hello,

We had a lot of that and it seems that there is/can beseveral issues.

1a: I suppose our chepish raid-controller
has a but of defect, flawd memory chip
or something that could corrupt data
some times.
- if anyone has a tool that writes
and reads disc fiersly and keeps
checksums of the data I would love
to have it run at idle priority
for few days to very this theory
1b: Some other hardware defect or driver
bug /defect, maybe.
1c: we also removed Sheduled Defragmentation,
but not so sure that it had anything to do
with it, but clearly possible. Because
on meny servers we'll defragment disk
and had not a single DB-corruptions.
But it woudl be possible cause, at least
JkDefrag will lock the file when it defrags
it or it is not accessilvle and if FB crashes
between writes and forced writes are off,
it seems to me that it potentially could
brake the DB.

(we get rid of most of the errors when moved
DB to the from raid to regulad SATA-drive)

2: It seems that some DB corruptions han survive
Backup restore procedure. I sugges that
you make new empty DB on the different drive
and pump data from theold DB, before that you
might need to make sure that all record are
readable etc. Hope that DB is not that big
that you can't do this. With Interbase
Data Pump this can be done easyly

Sotty that I can't give you more specific information of the process it
self, and those theroryes are not 100% verified, but that was the impression
of steps we had to take.

Hope that this helps even a little...

-TP-