Subject | Re: [firebird-support] Re: Start/Stop FB from a program |
---|---|
Author | Nando Dessena |
Post date | 2004-12-14T07:25:38Z |
Alan,
A> so are we going to sully the good reputation of Firebird by now having
A> endless corruption reports? And are we all going to just tell the people who
A> complain of these corruptions that it's all their fault for writing rotten
A> application code?
Firebird already has a reputation for corrupting databases more often
than other DBMSs. That's mainly because people install it on
inadequate machines, disable the forced writes setting and then plug
the cord, copy the database file while it is in use, connect while the
restore is in progress, do DDL while others are connected, make the
garbage explode by setting up sloppy transactions and never doing
backup & restore... I could go on. You just need to add to the list
that, since fbembed runs in the same address space as the embedding
application, nothing stops a misfire from the application to wipe out
something interesting like the TIP from the engine's memory. Of course
applications don't usually behave like wild cowboys, yet I find the
line of warning by Olivier absolutely appropriate. If you're going to
embed a database engine into your application, you'd better know what
you're doing. I have not experienced any problems so far, but it is
theoretically less sound than a separate-process setup. I'd expect
crashes more than data corruption, but anything can happen.
Ciao
--
Nando Dessena
http://www.flamerobin.org
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================
A> so are we going to sully the good reputation of Firebird by now having
A> endless corruption reports? And are we all going to just tell the people who
A> complain of these corruptions that it's all their fault for writing rotten
A> application code?
Firebird already has a reputation for corrupting databases more often
than other DBMSs. That's mainly because people install it on
inadequate machines, disable the forced writes setting and then plug
the cord, copy the database file while it is in use, connect while the
restore is in progress, do DDL while others are connected, make the
garbage explode by setting up sloppy transactions and never doing
backup & restore... I could go on. You just need to add to the list
that, since fbembed runs in the same address space as the embedding
application, nothing stops a misfire from the application to wipe out
something interesting like the TIP from the engine's memory. Of course
applications don't usually behave like wild cowboys, yet I find the
line of warning by Olivier absolutely appropriate. If you're going to
embed a database engine into your application, you'd better know what
you're doing. I have not experienced any problems so far, but it is
theoretically less sound than a separate-process setup. I'd expect
crashes more than data corruption, but anything can happen.
Ciao
--
Nando Dessena
http://www.flamerobin.org
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================