At 07:58 PM 31/03/2005 +0000, you wrote:

> > 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
>
>If the problem were as you describe, then the ODBC connection would
>*never* work, rather than only working when no-one else is logged into
>the database. Also, in this case we are using IP addresses rather than
>host names, so DNS can't be the cause.
>
>So my original problem still exists.

You can eliminate DNS resolution as a problem. As you say, if that were
the problem, it would throw a different kind of error. (BTW, case is not
an issue on Windows).

However, what I believe you are continuing not to see is the difference
between two inconsistent path expressions. It is *that* inconsistency that
causes the exception you are experiencing. YOU might think that
"d:\path\MyDb.fdb" and "d:path\MyDb.fdb" are the same because Windows will
allow either. They are NOT the same. When both are allowed, you get
corrupt databases. So Superserver's strategy is to allow either, but not both.

Firebird will let the first connection use either format. However, in
order to protect the database from corruption if multiple connections use
BOTH, it locks the database file exclusively as soon as the first
connection is connected.

So - if the database file was opened as "d:path\MyDb.fdb" then no
connection can be made to "d:\path\MyDb.fdb"; and vice versa. Your logic
that "if it's OK sometimes, it should be OK every time" is faulty. If your
connection is the one that initiates the exclusive lock, then you will
win. If the other application was the one that cause the lock to be
initiated, then it won and you can't get in.

./heLen