H
Heapy
Here's the situation:
- My db is located on a shared network folder. It's security (.mdw) file is
in the same network directory as the db.
- db users are given a shortcut to access the db, which runs access from the
local ws, opens the db on the target network share, with the workgroup
switch also specifying the .mdw to use to open the db.
All ran fine for the last three months, then all of a sudden (i.e. this
morning), an error when attempting to access the db:
"The database xxx needs to be repaired or isn't a database file" "You or
another user may have unexpectedly quit Microsoft Access while a Microsoft
Access database was open. Do you want Microsoft Access to attempt to repair
the database?"
- When I select "YES", one of two things will happen:
a) if another user was able to succesfully sign on (i.e. before me), I'll
get an error message to the effect that the db is already open exclusively
by another user (and the user information on that other user disclosed by
Access happens to be me, which is weird as I'm just in the process of
signing on)
b) if another user is not currently signed on, Access may or may not proceed
with the repair/compacting process. If the repair/compacting process is
allowed to run, upon completion all seems to be OK until the problem
restarts all over again.
A couple of notes:
- I've been able to ascertain that just before the problem occurs (i.e. I or
someone else is denied access to the db) a PREVIOUS user who has just signed
off will not have had his/her entry cleared from both the db lock file nor
from the .mdw lock file. I can confirm users exit the db "properly" because
my code intercepts and cancels the close event, in order to perform some
logging, and then executes a DoCmd.Quit to clean things up. Users who are
able to connect have not reported anything unusual about their sessions, and
the exit process runs as it always has. The only noticeable difference seems
to be (as mentioned) that the user's entries are not being cleared from the
locking files.
- Repairing and compacting the db does fix the problem, however this is only
possible after everyone who has been able to gain entry has exited, leaving
no one connected. In this case, the repair/compact process seems to
co-operate as long as it's initiated by the user who's entry in the locking
file is "stuck".
I have never seen this before - and what's even more strange is that this
thing ran fine for months. The ONLY changes that were made (recently) that
might be cause for concern relate to some security changes, in that all
users (except the db admins) receive their permission to access querries and
forms by virtue of their membership in one of several groups they may be a
part of, whereas the original design saw several groups having access to a
query or form. Table access is read only, with write permissions granted
through the use of owner's permission querries.
Finally, I have noticed (... when I am able to connect) that at times the db
will complain before updating a record through an error message something to
the effect that the file "xxx", where "xxx" is the path/filename to the db
the user is signed on to, is not in a recognized format, which doesn't make
a lot of sense. "Help" offers the explanation that this error may occur in
the event of a record commital problem where another user is holding
uncommitted records... this is also a new problem.
Sorry for the long message - I'm stumped. Any ideas?
Thx
HWH
- My db is located on a shared network folder. It's security (.mdw) file is
in the same network directory as the db.
- db users are given a shortcut to access the db, which runs access from the
local ws, opens the db on the target network share, with the workgroup
switch also specifying the .mdw to use to open the db.
All ran fine for the last three months, then all of a sudden (i.e. this
morning), an error when attempting to access the db:
"The database xxx needs to be repaired or isn't a database file" "You or
another user may have unexpectedly quit Microsoft Access while a Microsoft
Access database was open. Do you want Microsoft Access to attempt to repair
the database?"
- When I select "YES", one of two things will happen:
a) if another user was able to succesfully sign on (i.e. before me), I'll
get an error message to the effect that the db is already open exclusively
by another user (and the user information on that other user disclosed by
Access happens to be me, which is weird as I'm just in the process of
signing on)
b) if another user is not currently signed on, Access may or may not proceed
with the repair/compacting process. If the repair/compacting process is
allowed to run, upon completion all seems to be OK until the problem
restarts all over again.
A couple of notes:
- I've been able to ascertain that just before the problem occurs (i.e. I or
someone else is denied access to the db) a PREVIOUS user who has just signed
off will not have had his/her entry cleared from both the db lock file nor
from the .mdw lock file. I can confirm users exit the db "properly" because
my code intercepts and cancels the close event, in order to perform some
logging, and then executes a DoCmd.Quit to clean things up. Users who are
able to connect have not reported anything unusual about their sessions, and
the exit process runs as it always has. The only noticeable difference seems
to be (as mentioned) that the user's entries are not being cleared from the
locking files.
- Repairing and compacting the db does fix the problem, however this is only
possible after everyone who has been able to gain entry has exited, leaving
no one connected. In this case, the repair/compact process seems to
co-operate as long as it's initiated by the user who's entry in the locking
file is "stuck".
I have never seen this before - and what's even more strange is that this
thing ran fine for months. The ONLY changes that were made (recently) that
might be cause for concern relate to some security changes, in that all
users (except the db admins) receive their permission to access querries and
forms by virtue of their membership in one of several groups they may be a
part of, whereas the original design saw several groups having access to a
query or form. Table access is read only, with write permissions granted
through the use of owner's permission querries.
Finally, I have noticed (... when I am able to connect) that at times the db
will complain before updating a record through an error message something to
the effect that the file "xxx", where "xxx" is the path/filename to the db
the user is signed on to, is not in a recognized format, which doesn't make
a lot of sense. "Help" offers the explanation that this error may occur in
the event of a record commital problem where another user is holding
uncommitted records... this is also a new problem.
Sorry for the long message - I'm stumped. Any ideas?
Thx
HWH