On Fri, 10 Dec 2004 17:37:16 +0100, Olivier Mascia wrote:

>
>Hello Nando,
>
>On Fri, 10 Dec 2004 17:21:50 +0100,
>Nando Dessena <nandod@...> wrote:
>

<snipped parts of the original message>

>
>ND> I don't buy the argument that Firebird is less prone to crashes and
>ND> memory overwrites than my own application, just because it is
>ND> Firebird. If I decide to host database engine threads in my own
>ND> process space I should know what I am doing, of course, but I wouldn't
>ND> rule out the option beforehand.
>
>My point is that _if_ your app goes mad, it can get the embedded server
>to do dirty things to the database. And the reverse too : if the
>firebird embedded server goes mad, it can have adverse effects on your
>hosting app. Running both in their individual space, does not make any
>of them better. It is just that they can't collaborate to bring chaos.

My point of view is that embedded could be a server instance separate
from app that use (for example) interprocess communication (I'll call
it
" ITPComm" for short) to get the sql queries. Sure, in this scenario
will exist
a client dll and server separate (on same directory) and the client dll
will start
the embedded server when it's not active. Of course, you could use
TCP/IP loopback making that server listening at
127.0.0.<anything>:<anyport>
as a alternative for ITPComm

What is fastest? I really don't know, but I guess that ITPComm will be
faster
since it doesn't have check over the networking stack to get the
result.

I think it can solve both problems: a server "hidden" inside a
application and
no interference at other IB and FB servers on the same machine.