At 05:41 PM 7/01/2005 -0600, you wrote:

>From: "Helen Borrie" <helebor@...>
> >
> > There is (by design) no distinction made at the API level. It's the
>client
> > that decides which server engine it's going to connect to. The embedded
> > library can be a client to *any* running server except a fully installed
> > server that is running on the same machine. The client requests a
> > connection to a server engine and, if a connection is allowed, it is
> > made. End of story.
>
>Helen,
>
> I have IB 6.0.2 and FB 1.5 SS running on my machine. I also use the
>embedded for one application. The application has the ability to switch to
>the (FB) server instead of embedded to allow sharing. So far, everything is
>working fine. Are you saying that I shouldn't be able to connect from my
>application to the server on the same machine?

No. If you have a "full server" running on the same machine, then your
(version of) fbembed.dll can connect to that server via localhost just as
the "regular" fbclient.dll does.

If you have only the embedded server available, then connection via
localhost will be refused.

Does that clarify?

>Or, is there some other
>reason like possible corruption as in the case of the past history with
>using local/remote paths at the same time.

No. And, for the record, there was NEVER a potential for corruption by
using local and remote paths at the same time. The potential for
corruption came from having different clients using different Windows path
formats to connect to the same database (and this potential is still there
with IB 6.0.2, be warned!!) This was known as "the connection string
bug". It was fixed in Fb 1.0 Superserver, by making the server open the
database file with an exclusive file lock. (The Xlock is also the reason
why an embedded connection is exclusive, since the embedded engine is
SuperServer).

You can still use this method to corrupt Firebird databases if you're using
Classic server on Windows.

Helen