Access Error when opening shared database

[Guest]

I have an network share access database that is opened in shared mode with no
locking set on the file. DDE refresh is enabled
60 sec DDE timeout
Refresh interval is 20sec
Number of retries is 6
ODBC refresh is 30sec
Retry is 100msec

We have found that if the main user (a 24x7 operation) keeps the database
open for a significant period any other user who attempts to open gets the
following error:
The database has been placed in a state by <user> <computer> which prevents
it from being opened or locked.
Sometimes having them hit "save" removes this error, but mostly they have to
completely close down and re-open.

Any ideas on what might cause this and what a fix might be?

 

[Joseph Meehan]

I have an network share access database that is opened in shared mode
with no locking set on the file. DDE refresh is enabled
60 sec DDE timeout
Refresh interval is 20sec
Number of retries is 6
ODBC refresh is 30sec
Retry is 100msec

We have found that if the main user (a 24x7 operation) keeps the
database open for a significant period any other user who attempts to
open gets the following error:
The database has been placed in a state by <user> <computer> which
prevents it from being opened or locked.
Sometimes having them hit "save" removes this error, but mostly they
have to completely close down and re-open.

Any ideas on what might cause this and what a fix might be?

Could any of the users be shutting down their computers without exiting
Access?

 

[Guest]

I would categorically say no. There is one user that has it open pretty much
24x7 on their machine and then added users who access to run short reports
and log back off. The error is too consistent for it to be that and that user
is definately not shutting their computer off without exiting their
applications.

My completely unscientific idea is that they make too many data changes and
the dB is waiting on an update. Like the 'temp memory' use is too much to
juggle multiple users. Manually saving the file will often fix, but not
always.

 

[Joseph Meehan]

I would categorically say no. There is one user that has it open
pretty much 24x7 on their machine and then added users who access to
run short reports and log back off. The error is too consistent for
it to be that and that user is definately not shutting their computer
off without exiting their applications.

But what about the other users?

My completely unscientific idea is that they make too many data
changes and the dB is waiting on an update. Like the 'temp memory'
use is too much to juggle multiple users. Manually saving the file
will often fix, but not always.

Access basically saves as it goes. However you could be experiencing
some sort of record locking issue. I have found that when I had a lot of
people entering data, it worked best by setting each one up with a local
file to enter the data into and then batch processing that local data to the
central back end at the end of the day when other traffic is slow. I
assigned staggered times for them.

BTW you are using a split system? One backend and a frontend on each
user's machine? If not, you should. It helps eliminate all kinds of
strange problems.

 

[Guest]

I would say that it is highly unlikely to the point of impossible for another
user to be shutting down without closing this consistently. I have also
verified that there are many times when there were no other concurrent users
the whole duration. I have seen that sort of disconnect behavior before and
it usually takes a lot more to fix.


It is not split at this time, but is planned for the next version. I didn't
control the original and have been slowly normalizing things like that. I
didn't think it would make a difference to this, but if it does then I will
up that in my priorities

 

[Joseph Meehan]

I would say that it is highly unlikely to the point of impossible for
another user to be shutting down without closing this consistently. I
have also verified that there are many times when there were no other
concurrent users the whole duration. I have seen that sort of
disconnect behavior before and it usually takes a lot more to fix.


It is not split at this time, but is planned for the next version. I
didn't control the original and have been slowly normalizing things
like that. I didn't think it would make a difference to this, but if
it does then I will up that in my priorities

Oh I do think it may well be the answer to your problems. Access does
not like many users using the same database at the same time.

 

[Guest]

I am having a similar problem and thought it might be related to the advanced
options tab settings I have. My settings are: ole/dde timeout - 30; Refresh
interval - 60; number of update retries - 2; ODBC REFRESH INTERVAL = 1500;
update retry interval 250.

On a form with many tables on screen linked, ONE table's form is giving a
message "currently locked". I'm wondering if it has anything to do with my
settings. I know it give a range for each setting, but what are the
"default" setting for each of the advanced settings .

I also have check the box "Open databases usin record-level locking".
Default record locking is set to "No Locks" and Default open mode is "Shared".

Any help would be appreciated. I've exhausted all my ideas.
Thanks.
connie