At 08:34 PM 30/03/2005 +0000, you wrote:

> > >Any more thoughts from anyone on this?
> >
> > Configure ODBC data source to use exactly the same connection
> > string as Deplhi application.
> > BTW, this connection string should be in form
> > <server name><protocol sign><DB file path from FB _server_ POV>
> > --
> > SY, Dimitry Sibiryakov.
>
>Thanks for the suggestions. I contacted the developer of the Delphi
>application and got the connection string. The connection string I am
>using is exactly the same as the connection string used by the thick
>client, and the problem still persists. It looks like this:
>
>dbhost.mydomain.com:D:\database\databasename.gdb
>
>As I said, I can connect through ODBC just fine to an instance which
>has no other connections, and multiple instances of the thick client
>can all connect at the same time, but I cannot connect through ODBC
>and get the "Connection failed! File database is in use by another
>process." error when trying to connect when any thick client instances
>are also connected.

OK, what that is telling you is that the connection string coming from the
ODBC connection is inconsistent with the one coming from the thick
clients. You should therefore find that, if your ODBC connection succeeds,
none of the thick clients will be able to connect.

>So, I'm still at a loss to explain this. It seems strange that
>multiple thick clients can all connect, and that I can connect through
>ODBC when no thick clients are connected, but that I cannot connect
>through ODBC when any thick clients are connected.

It's not strange at all, it is designed deliberately that way. If
connections via inconsistent paths are allowed (as they are in InterBase)
you will corrupt your database. This is a Windows quirk.

>Sorry to sound like a broken record, but once again, any more thoughts
>from anyone? Anything else I should be doing to track down the
>problem? Seems like it has to be something obvious I'm just missing.

We know the cause now. Your challenge is to track through the network
setup and find out why dbhost.mydomain.com is resolving to something
different in your DSN to what it is resolving to when the thick clients
connect.

./hb