Hello everybody,

I had a strange effect on a customer's system today. We usually deploy
our application with a minimal Firebird client. So the application
folder contains
MyApp.exe and
fbclient.dll and a few other application-related files.
We are using the current incarnation of Firebird 2.5.2.26540, for both
server and fbclient.

Usually the app folder is shared (read-only) and people start
MyApp.exe from their clients. This is easy to set up and works
perfectly.
\\myserver\myapp\MyApp.exe

The installation today was on a Windows 2008 64-bit server that serves
as a database server and serves this file share at the same time. When
we started the application from a client, the program came up
immediately, but the connection to the database took very long (10 to
20 seconds). After that, database communication was fast and normal.

When I copied the folder to the local client, the connection was
established immediately. Deactivating virus checks on the server did
not help.

When I share the folder *above* my application folder, the connection
is also established immediately and very fast.

My suspicion to what is happening here is:

During connection establishment, fbclient.dll tries to load a file it
usually finds one level above itself (firebird.conf? firebird.msg?
firebird.log?)

As my program starts from the "root" of a Share, there is no parent
folder, but it takes some time until the OS reports that back (some
sort of timeout when trying to access \\myserver instead of
\\myserver\myshare ???) - so I suspect that is what takes so long.

When the app folder is a sub-folder of the share, fbclient.dll
immediately finds that empty folder one level up. As it can work
perfectly without firebird.msg (or whatever it tries to read there),
everything goes well from there on.

Can somebody confirm that this is/was the problem?


Best Regards

Stefan Heymann