--- In firebird-support@yahoogroups.com, "Jeff Lynn" <jmlynn@...>
wrote:

>
> I found it. My bad! I was testing with FBEmbed.dll renamed to
> fbclient.dll in my standalone app, yet when I was testing another

app

> using a DLL, it some how found the client/server based fbclient.dll
> instead of the much smaller FBEmbed.dll.

FBEmbed.dll is about 5 times larger than the standard client library,
so I have no idea why you are expecting a smaller one. The embedded
library ~1.5MB, the normal library ~350KB. The embedded library will
behave as a normal library if it is given a TCP connection string
(servername:c:\path\to\db.fdb) instead of a direct connection string
(c:\path\to\db.fdb)

>
> I don't know, just wonder why Firebird developer didn't release a
> proper named DLL pair such as FBEmbed.dll and FBEmbed.lib instead of
> having to rename it to FBCLient.DLL.

This has nothing to do with Firebird. Firebird doesn't care what it
is called, call it fred.dll and it will still work.

Your connection components call functions within the DLL. **Some**
connection components allow you to define within your program the
name of the dll. Many though expect to see a dll with a given name
such as gds32.dll or fbclient.dll.

> I can see it may be more convienent to test against host based serv
> and then without any change, release it as stand-alone "embedded"
> version. But it sure confuse the diagnostic problem.

Not at all. If your connection components support an arbitrary named
dll, then you just include in your ini file with the rest of the
hostname and aliasname parameters the name of the dll to connect to,
simple.

Adam