Helen Borrie wrote:

>>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.
>
>
>
>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
>
>
>
>
>
>

Hello:

His connection strings (both those thick clients and for his ODBC setup) are of the form:

111.22.33.44:c:/......

rather than

somehost.somedomain:c/......

so DNS is not involved.

Poney: Are the strings identical, including case-sensitivity?

Dennis McFall