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

I am not here to "defend" FB, just to supply a very different vision
from yours.

I work with Firebird/Interbase for 8+ years, had a database corrupted
only once (and it's not FB fault, my costumer disks failed).

I am not following this list as close as I used to do (to much work, to
few available time), so pardon me if you already discussed it earlier.

1.) Did you set you database to use "forced writes"
2.) Are you sure you have not fault hardware ? (bad disk, bad memory,
etc.) ?

I have to disagree that FB is not suitable for "serious product
environment", if you reach a FB bug that leads to database corruption I
am sure the FB developers would follow it closely to remedy this
situation ASAP.

I have 300+ years of Firebird databases running flawlessly, and I am
sure there are people with much more than this...

My post don't give you solutions, neither any kind of help to identify
the root reason of your database corruption, but I am sure you did not
did a bad choice for FB, I didn't work that much with MSSQL (just around
3 years), and I had listened to histories of very bad corruptions but
did not saw one in person.

In my case FB uptime is more than 99.999% which makes me think FB is
very suitable for "serious production environment". Then only "downtime"
is needed on application upgrade (which needs metadata updates) and I
like to do it on weekend's with everyone off-line.

Now, talking about your back-up "feature request", it could be easily
implemented with one way replication to another machine. A trivial task
implemented with triggers and a client program that read a table on the
master database and replicate it as SQL instructions to the slave
database. I think it could be done in no more than a full working day
(of course it's not anything near a full replication utility).

Another approach would be make the replication log a separated database
and in case of corruption make a application that would generate a SQL
replay session using those data against a restored database from the
last gbak back-up (as the above an easy task to implement). Perhaps
because I had never lost anything with Firebird, I don't see a "reason"
for such approach, but if I though I have a weak RDBMS that could lead
me to data lost I would think about it (or look for a more robust RBMS).

I had costumers that would lose a million dollars with a 3 hour
downtime, if I don't believe on FB robustness I would never put my head
on a such game.

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br