--- In firebird-support@yahoogroups.com, "lysander_fb"
<lysandersyahooadress@g...> wrote:

> --- In firebird-support@yahoogroups.com, Svein Erling Tysvær
> <svein.erling.tysvaer@k...> wrote:
> > ...one of the benefits of
> > Firebird not being dBase is that Firebird is far more robust and that
> > corruption rarely occurs unless there is some sort of disk problem
>
> while I am here because I am enhancing and converting FROM dBase TO
> Firebird, and I really like what I see and experience, this statement
> needs a bit of correction. I have been writing successful network
> applications with dBase for more than 10 years, and did not have one
> case of corruption in my own network.
>
> Those cases I saw in other applications ALWAYS were because of very
> bad mistakes in database- and applicationdesign, and those 'designers'
> would surely be capable to crash a Firebird server with the twist of
> one finger...
>
> ciao,

Hello André,

You are right that most corruption is caused by design errors, but
there are a couple of things here where Firebird stands out.

Firstly, it is ACID!

Failures will happen, and murphy said they will happen at the most
inopportune time. If a failure happens at any point in time, then
Firebird WILL come back in a valid state (providing the disk didn't
die). It may have some garbage collection to do because any active
transactions at the time of the crash would need to be rolled back,
but this will not affect anyone.

This is a stark contrast to Paradox / DBase etc, where a problem
during a write might leave a record in an invalid state.

There are only three ways I can see that an application developer
could accidentally stuff a database.

1. Inside a UDF
2. Running in embedded mode
3. Turning Forced Writes Off

The solution is pretty simple in Firebird, run gbak, then restore the
backup to a different location and do that frequently. I can assure
you that since moving to Firebird from Paradox, despite having about 5
times as many installations, we have not had a single piece of data
lost due to a Firebird database corruption. Yes we have had to run
gfix (once) to fix some record level issue on a single table, but then
again that server gave me the BSOD when I tried to copy a zip file in
explorer, so I don't for a moment believe it was Firebird that caused it.

Adam