Thank you.
I have used Interbase / Firebird for about 7 years now. Until version
2.0 I had zero problems.
The forced writes issue is supposedly fixed in version 2.1. The
database is certainly set for forced writes.

I don't expect any software to work perfectly.
Good design provides useful contingencies for this.

Interestingly enough I started work on a replication system very
similar to the one you describe. It simply sets triggers to copy table
names and primary key values to a table. An external process then
copies the data to the replication server. I will have to finish it.

Michael Boyle.

--- In firebird-support@yahoogroups.com, Alexandre Benson Smith > 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
>