Tim,

T> Under what circumstances should I as a developer consider using FB Embedded
T> rather than FB?

- you only need to access the database from a single, local process at a
time and you need the best possible performaces. An embedded database
connection beats any other protocol in terms of throughput.

- you need to develop a client/server application in which the server
part needs to be smarter than a database server (i.e. should provide
additional application services) and you don't want/need to turn it
into a 3-tier system. In that case, embed Firebird into your
application server and there you go.

- you have a single-user (1-tier) application that needs local
storage support with the minimum possible impact on the target system.
There are plenty of solutions for this kind of deployment, but fbembed
beats them all in flexibility and feature-richness.

- you have a client application in a C/S scenario (the server being
Firebird) that needs to connect to the server and also needs local
storage (perhaps as backup for when the C/S link is broken, perhaps as
an aid for local processing). In that case you use fbembed as both an
embedded database engine and as a client for an external Firebird
server.

- should any of the conditions that made one of the above scenarios
interesting change, you can upgrade to Firebird stand-alone
seamlessly.

There could be other scenarios, these are the ones I have tried and
use. If we acknowledge that having a real "embedded server" (as
opposed to an embedded "engine", which is what fbembed.dll is) is a
good idea, which I expect to happen somewhere around the 3.0 release,
there are even more appealing deployment scenarios.

HTH
--
Nando Dessena
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================