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

it's theory and conjecture at this stage since noone has reported suspicion
let alone definitive proof.
Theory is: embedded is a DLL which is loaded into the application's memory
space - unlike the remote server setup where the server has it's very own
memory space.
If your application fools around with pointers and you go awol with your
addressing, you could potentially march over the server's memory without
raising an OS exception. The result may be very strange server actions or
corrupt data. But in a Delphi application where user executed pointer use
(i.e. not VCL) is often not present, it's highly unlikely.

Alan

>
> --- 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
>
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>