At 04:55 PM 7/01/2003 -0800, you wrote:

>An issue has been reported to me by one of my users. I tested it myself,
>and I get the same result.
>
>This is on XP. I haven't tried it on other versions of Windows. If you
>log onto as an administrator, you can log on fine. If you long on as a
>Windows user that is a "Limited User", rather than an Administrator, you
>can not. The error received is simply "Cannot open file".
>
>I put some debugging error messages in my code, and narrowed it down to the
>following line (TheDB is a TIBODatabase):
>
>TheDB->Connected = true;
>
>I put debug statements directly before and after that line. The one before
>hits, then it executes the above line. This causes the IBO default login
>dialog to open. They enter the userid and password, and when they click
>OK, an error message box comes up. The title is the name of my app. The
>text simply says, "Cannot open file", with an OK button. If you click
>"Ok", it goes back to the login box again. It lets you try 3 times, and
>then an exception is raised ("Login Failed" is the text of the exception).
>
>There are no event handlers in TheDB, and I've searched my code for the
>text "Cannot open file", and it's not there, so the message must be getting
>generated by IBO.
>
>Does anyone know what the issue is? Again, it works fine if you log on as
>Administrator first, but not as a restricted user. How can this be
>fixed? My customer has definite issues with giving their users
>administrator rights on the local machine.

Joe,
The message is coming through to your application from the operating
system, not the database: IBO's response will be to attempt login up to
the number of times specified in the LoginAttempts property and then to fail.

The first user to log on causes the server to request at filesystem level
that the database *file* be opened. If the file can't be opened, then you
get the behaviour you describe. The interbase.log on the server (in the
server's root directory) may tell you more, e.g. supply a NOS error code
that might help to identify what is stopping the server from opening the file.

The cause will likely be one of the following:

either

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;

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.

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.

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);

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.

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

regards,
Helen