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.

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.

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.


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.