Evening all,

replying to myself - after a little experimentation.

I wrote a small IBPP test utility that connects to an embedded FB
database as well as connecting to a database using local protocol.

I had full FB installed on the same box, but not on the PATH. In theory,
the test app and FB server should have been completely separate. Ha!


1. With embedded running (ie, all the Fb Embedded DLLs etc are located
in the same folder as the application executable) then if the embedded
app gets a connection first, neither local or client can connect to the
same database.

2. If embedded is running and attempts to connect to the database when
either local or client are already connected, then the app will fail to
connect.

3. If the embedded DLLs etc are removed, leaving only the app
executables etc, then the app is attempting to connect locally. (No
server name is passed to the connection details.) In this case, the app
will connect regardless of whether any other client or local connections
are already connected to the same database.

Now, I was puzzled here for a bit as IBPP was connecting to the database
when there was no FB files on the PATH - and gds*.dll had been removed
from windows\system. How come?

It seems that IBPP is quite intelligent in that it looks for
fbembed.dll, fbclient.dll, gds<whatever_i_forget!>.dll and also, looks
in the registry to see where the default instance of FB is installed to,
and picks up the clinet software from there.

That had me confused for a bit!

4. So, the only time I have connection problems is when I have FB
Embedded running alongside any other form of connection type. This is as
expected but is now confirmed to my own satisfaction.


Cheers,
Norman.