Locked out (briefly) during data entry

[David Portwood]

I have a muli-user app deployed with split db. The data entry people
complain that occasionally when they try to begin entering data into a new
record, the app seems to "freeze" and won't let them type anything.
Sometimes it unfreezes and continues, sometimes an error message is
displayed: "Could not update; currently locked."

I think this may be occurring because other users are clicking a Report
button that I have on the app. The report queries the same table that the
data entry people are entering data into. I think when the report collects
data it locks the table.

Could this be the case? If so, is there anything I can do to improve the
situation? For instance, is there perhaps a query restart option where I can
tell Access to just go ahead and run the query/report and ignore any user
updates that might be occurring simultaneously? In this way the data entry
people won't notice a "freeze"?

 

[Joseph Meehan]

Having a lot of people on the same database, especially when some are
intense users can be a wee bit of a problem. Access needs to lock out one
user to allow another user to make changes.

One "solution" is to batch process the data entry functions. This is
not a perfect solution but it worked well with the applications I had.

Set up a temporary table to allow the data entry work to be done on the
front end. Then at the end of the day "process" that data against the data
on the back end. It will not work for every situation.

 

[David Portwood]

Having a lot of people on the same database, especially when some are

intense users can be a wee bit of a problem. Access needs to lock out one
user to allow another user to make changes.

One "solution" is to batch process the data entry functions. This is
not a perfect solution but it worked well with the applications I had.

Set up a temporary table to allow the data entry work to be done on the
front end. Then at the end of the day "process" that data against the
data on the back end. It will not work for every situation.

This is an interesting idea, Joseph. In fact, I don't think it should be
necessary to wait until the end of the day to batch the updates.

If data entry was made to a new intermediate shared table I think I could
run a local program from a timer on my workstation to periodically (maybe
every second) check for new records in that table and then let my program
update the main table. In this case, I would be the one to experience the
"freeze" if another user was running reports or queries. Nobody would be
running reports or queries against the intermediate table so the data entry
people should never see any delays.

But before I go that route I will ask a few general questions of the group
to make sure I'm understanding the situation...