|Re: [IBO] "Cannot open file" error
>the server service doesn't have permissions to access the database file'sRight. I know that the server service can access the database file because
>directory. This seems unlikely, since you say that the Administrator can
>open the file;
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.
>orThis isn't it. There are only two connections to the database: the server
>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
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:
The client uses:
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 yourThis shouldn't be it either. The database file has the extension .FDB,
>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.
which as I understand it, is not bothered by System Restore.
>orNope. See the path example above.
>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);
>orBoth computers are using the gds32.dll that comes with FB 1.
>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.
>It is also helpful, when reporting connection problems, to give details ofThe server is running Windows 2000 Server.
>the environment - including the network protocol.
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?