> Thanks for your great explaination. Yeah my application is actually
> a 4-tier thin-client server model:
>
> Client <==> business-sever <==> data services <==> datastore.
>
> And my application has been using MSSQL as datasotre.

In this design MSSQL can be replaced by FB server. If you intend to
reduce communication overhead think about merging "business-server"
and "data services".

Having the "full server" is certainly the better choice on
multi-user-applications.

> Since Firebird opens more opportunity and high performance, my data
> service tier is likely to embed Firebird.

The embedded server is designed for single-user applications. You
should not try to extend this back to multi-user.

> However, to be embedded, it also needs to open a door for other
> third party applications to access the server.

The embedded server does service an single process only. If you intend
to let another process access the database you should got to the
non-embedded server.

Alternatively you might implement an communication path of your own -
but, I would never do that for general use (much work, less efford,
stability of main application).

For an single-user application I did such an communication path based
on DDE (simple but incompatible to any existing DB-software): An
auxiliary EXE can send a few SQL queries to the main application.

> Again the ultimate question is "acoording to your comment, an
> embedded Firebird server does NOT support remote accessing such as
> ODBC?"

That is true, embedded server does not open any communication path to
access database from outside.

Elmar