--- In firebird-support@yahoogroups.com, "dancooperstock"
<dcoops@s...> wrote:

> (I've had some correspondence about this on the IB-Conversions list,
> but I was advised to move it here.)
>
> I am the developer of a free program with over 2,000 users, currently
> using Sybase Adaptive Server Anywhere for its database. For various
> reasons, I'm considering switching to Firebird.
>
> My concern is that it has to be absolutely rock solid, zero
> administration, and as close to zero problems (e.g. database
> corruption) as possible. With Sybase ASA, I think in 5 years of
> supporting my program I have had only 1 or 2 users who have actually
> had a problem with their database.
>

The first thing you will want to do is to get a copy of The Firebird
Book. There are some basic rules to follow when using Firebird, mainly
centered around managing transactions.

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_firebird_book

The Firebird engine itself is solid. We have had over 300 sites, some
running since Q1 2004, and we have not lost a database due to
corruption. We had a single instance of record level corruption that
was fixed using gfix -mend (gfix ships with FB). Our environments
vary, from secure hosted servers with dedicated air conditioned
buildings through to cramped corners in some room out the back with no
ventilation, old and damaged hardware. It is of note that the single
instance of corruption occured on a "database server" (read old PC
that no-one was using anymore) that was so flaky that I got the BSOD
when trying to use explorer to copy a file. Make your own mind up as
to what caused it.

> I've asked here before, and was told that yes, Firebird is just that
> rock solid.
>
> However, I just read the first issue of The Interbase and Firebird
> Developer Magazine. I see there are ads in there for products like
> IBSurgeon (for repairing corrupted databases), IBFirstAid (for
> diagnosing and repairing common corruptions of InterBase and Firebird
> databases) and IBBackupSurgeon (for reading data from corrupted
> backups).
>
> The need for these programs has me worried about whether Firebird is
> really rock-solid enough for me to use as the embedded DB in my
> application or not.
>
> Under what sorts of circumstances do Firebird databases, and their
> backups, tend to get corrupted?

The engine itself is good. If you (or someone else) writes a UDF
incorrectly, then this may crash the server. I have seen this many
times (we recently found a culprit UDF function). This never corrupted
a database, but does cause the service to shutdown (which is
automatically restarted by FB guardian).

I would agree that the backups are a bit too prone corruption for my
liking. The simple procedure is after a backup, restore it somewhere
else and test it. With gbak, if there is a stored procedure, index,
constraint or trigger that is corrupted, the restore will fail. This
is not ideal IMO, because even though the backup is corrupt, you can
still theoretically rescue the data and pump it into a clean structure.

The database itself should only experience corruption if one or more
of the following conditions is true:

1. Forced Writes is off
2. You file copy the database file while someone is connected.
3. You make DDL changes (add fields and constraints etc) with users
connected.
4. You do not commit after making the DDL changes and try to just use
the fields.
5. You use embedded Firebird and your application does something nasty.
6. Putting the database file on a drive not under the direct control
of the server.
7. Faulty RAM, although this might only bring down the server, leaving
the database in tact.

So IMO you have to be pretty silly (or very unlucky) to loose data due
to corruption. You can test Rebooting, ending tasks, hard power off
all you like. Providing you don't kill the drive itself, it should
come back online fine, at least I have never seen this cause
corruption, let alone unrecoverable corruption.

Adam