>the server service doesn't have permissions to access the database file's
>directory. This seems unlikely, since you say that the Administrator can
>open the file;

Right. I know that the server service can access the database file because
the server computer can log into the database itself. The computer having
the problem is a network client, connecting over TCP/IP. Permissions to
open the database file should really have nothing to do with whether the
client is an administrator or not, since the client doesn't even touch the
database file directly.

>or
>
>you are using Firebird; a user (e.g. the NOS Administrator) has already
>opened the database file using one form of the connection string and the
>next DB user who attempts to log in is using a different form of the
>string. In InterBase, this is allowed, with devastating consequences; in
>Firebird, the first DB to open the db file gets exclusive access via that
>string, and no client with a "competing format" will be allowed to connect.
>
>This problem - known as "the connection path string bug" - has been with IB
>for years and has been well-documented since it was first discovered by
>Jason in 1999. The Firebird fix is documented in the Firebird 1 release
>notes.

This isn't it. There are only two connections to the database: the server
itself, and the client computer. Both are using the exact same connection
path, except for the server name at the beginning. e.g.:

The server uses:
C:\Program Files\TRS6\data\data600.fdb

The client uses:
MyServer:C:\Program Files\TRS6\data\data600.fdb

Plus, what would this have to do with whether or not the client is logged
in as administrator.

>Another (related) possibility, peculiar to XP and ME, is that your
>deployment hasn't taken care of the System Restore problem; so that, when
>the first user tries to connect, the System Restore "feature" has the DB
>file locked. Again, you can get enlightenment on this problem and possible
>solutions by studying the release notes.

This shouldn't be it either. The database file has the extension .FDB,
which as I understand it, is not bothered by System Restore.

>or
>
>the users are trying to connect to a mapped drive, a share, etc. (the
>network layer between the client program and the server must address a
>physical drive location);

Nope. See the path example above.

>or
>
>the client is trying to use a non-compatible client library to connect. It
>is necessary for each client to be running the version of gds32.dll that
>matches that of the server.

Both computers are using the gds32.dll that comes with FB 1.

>It is also helpful, when reporting connection problems, to give details of
>the environment - including the network protocol.

The server is running Windows 2000 Server.
The client is running XP.
Network protocol is TCP/IP

I really can't understand how what type of user is logged on to the client
could affect whether or not the server can open the database file. The
client doesn't touch the database file. That's the server service's
job. This makes me wonder if it's not the database file at all, but some
LOCAL file on the client that it's complaining about.

Any more ideas?

-Joe