You're the 2nd person that suggested that using embedded Firebird
(which is my intention) is a bit more risky. You said in
particular "you use embedded Firebird and your application does
something nasty".

Could you be a bit more specific about what my app might do that is
nasty?

Are there general problems about using embedded Firebird? The
intention, of course, is that this will be a single-user app.

Thanks.

--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...> wrote:
> --- 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