At 01:19 PM 24/06/2008, you wrote:

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

So this is a different site from the one you described a few days ago, when questioning what was going on with nbackup in v.2.1?

<< The LVM routine was established during V2.0. use of the database(s).
Although this database corrupted (gds inconsistency error) on average
every three months under 2.0 (never under 1.5) >>

>Of course the architecture of Firebird buries database corruption
>where it becomes costly to find e.g.
>
>Data corrupts at 9 am, next gbak is 23:30 pm. Corruption is discovered
>during nightly gbak which fails. Database from night before needs to
>be restored and entire day's data salvaged from corrupt database (if
>possible).
>Nbackup is useless as it just copies the problem.
>
>The only workaround is to manually log data into a separate database.
>
>This is a design fault so significant I could not recommend Firebird
>for use in a serious production environment.

..in *your* production environment...right? Firebird databases don't corrupt in a "serious production environment" but it sounds as if you are over a barrel now and it's too late for you to approach (with us) what is happening in *your* environment to cause this corruption.

>Firebird needs an external transaction logging system that allows
>reentry of data from last gbak session somewhat along the lines of a
>concurrent delta file but record based not page based. That would
>provide a useful restore function.

Firebird doesn't need an external transaction logging system, but if *you* do, then there is IBLogManager (Google it).

On Linux, Forced Writes doesn't work prior to v.2.1, so that's one safeguard you didn't have with v.1.5 and v.2.0.3 and below, if Linux was your platform.

>If I sound bitter it is because I have to get on a flight in 2 hours
>to discuss the implementation of MS SQL Server - something that I
>never wanted to do and a decision that was taken out of my hands.

Well, I you're on the way to the airport now and we (and you) have seem to have missed the opportunity to discover what has been causing your corruptions...or even what kind of corruptions they were...but it's there to be found, somewhere.

And, yeah, I can relate to your grief - not least the grief that awaits you with your new DB engine. Good luck with it.

./heLen