Olivier,

OM> If your program hang, then the embedded server too.
OM> If your program has a bug and wipes out a part of its memory space, the
OM> embedded server and its data structures (in your memory space) are at
OM> risk. This risk is even higher than a hard stop. It can lead to writing
OM> erronenous bytes in the database.

True.

OM> If you're concerned by robustness, forget the embedded dll.

this is a bit exaggerated, isn't it? I'd say if you're concerned by
robustness, then write robust programs. :-)
I don't buy the argument that Firebird is less prone to crashes and
memory overwrites than my own application, just because it is
Firebird. If I decide to host database engine threads in my own
process space I should know what I am doing, of course, but I wouldn't
rule out the option beforehand.

OM> If you want the server to be tightly integrated with your app, install
OM> its server components along with your app (through your own app setup)
OM> to some subdirectory of your application target. Ship a firebird.conf
OM> file preconfigured for your needs. You can even go as far as having your
OM> app start and stop the independent server when the app start/stop.

I'd add: choose a nondefault listening port, configure it to non create
an internal window handle and set the FIREBIRD environment variable
before starting it. That's what I do and it works satisfactorily.

OM> you run the database in a separate process space than the app. It is
OM> much more robust.

Again, it is more robust only if you assume that your application is not.

OM> Installing a per-application private copy of the server, as described
OM> (very shortly) above, involves installing some more files than a single
OM> DLL, yes. But not hundreds of files, not even tens of them.

You should look at the compared performaces. I have embedded Firebird
into a server application of mine that could never work with the
TCP/IP throughput Firebird provides, even locally.

OM> Embedded server in a DLL might be usefull for some short-running tools
OM> or utilities. For an application serving end-users, I would not even try.

I'd argue that it only depends on their robustness. I agree that
end user GUI applications tend to be less robust than servers on
average... :-)

Ciao
--
Nando Dessena
http://www.flamerobin.org