How to stop users from simultaneously updating a shared table

HI.  I have a shared access database that tracks returned goods and actions taken\pending.  I had some old email code that sent a separate email to each user where action was required.  This means a lot of email processing.  I am changing that to send out a single distinct email for action users and they can  now log into the database to view a report showing their specific actions.  To make this possible,  I turned all of the email alert code into a series update queries that  write to a table called RGAlerts.  I can run the refresh manually but I'd really like to refresh it each time the users either open or close the report, I'm not sure which would be best.  I have all of this working except for the report-driven table refresh.  I'm concerned about user updating simultaneously.  It would only hurt this one table that will get refreshed anyway but I think it could cause some confusion as that table could show duplicate entries if users happen to trigger the refresh at the same time..  
What is a good way to manage simultaneous updating in ACCESS 2010 and 2016?  Both clients are in place.  Is record locking possible to use in this situation?

thanks
LVL 7
valmaticAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Russ SuterCommented:
A lot of this is determined by how you want to handle things on the front end. First, do you want to use optimistic or pessimistic locking?

Optimistic locking is best used when the following conditions are true:
  • You're not expecting a lot of collisions
  • The cost of a collision is either not very high or you're willing to pay the high price for the rare occasion when a collision does occur
  • Absolute, up to the minute, 100% data accuracy is not required. Basically, it's OK if someone gets a slightly out of date version of a record

Pessimistic locking is best used when collisions are common or the cost of a collision is so high that it should be avoided. In this case if one user requests data that is pessimistically locked then they are just told they can't have it right now and should try again later.

Both approaches have their benefits in the right situations.
1

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Gustav BrockCIOCommented:
First, apply a unique index to the table to avoid duplicate entries completely.
Then, adjust your code to handle the error if a duplicate entry should be attempted.

If records are edited simultaneously, first try if this is a real problem.
If it is, you can apply the simple method described in my article:

Handle concurrent update conflicts in Access silently
0
valmaticAuthor Commented:
Thank you both for your responses.  I should have included my code with the post.  My code clears and rebuilds the table and if more than one person triggers the function call while the table refresh is already running then I get duplicate records.  This really isn't a record edit but a full table refresh, which takes about 5 seconds to complete.  It is likely that users will hit this thing at the same time so I think Pessimistic locking is best for this.  The function call is generated from a report request so I'll have to work in a warning to the users or make them aware they may need to retry the request again.  

Public Function RGAlerts()

    DoCmd.SetWarnings False
    DoCmd.RunSQL "DELETE * FROM RGAlerts"
    DoCmd.RunSQL "Insert into RGAlerts (RGAlertID) Values (0)"

    DoCmd.OpenQuery "AlertQry1_RGClosed_Initiator"
    DoCmd.OpenQuery "AlertQry2_CustRcptNoticeLate_Initiator"
    DoCmd.OpenQuery "AlertQry3_CustDispoNoticeLate_Initiator"
    DoCmd.OpenQuery "AlertQry4_LateEval_QI"
    DoCmd.OpenQuery "AlertQry4_LateEval_QM"
    DoCmd.OpenQuery "AlertQry4_LateEval_QIA"
    DoCmd.OpenQuery "AlertQry5_EvalsUnstartedDue1Day_QI"
    DoCmd.OpenQuery "AlertQry5_EvalsUnstartedDue1Day_QM"
    DoCmd.OpenQuery "AlertQry5_EvalsUnstartedDue1Day_QIA"
    DoCmd.OpenQuery "AlertQry6_RelFromHoldPendingEval_Initiator"
    DoCmd.OpenQuery "AlertQry6_RelFromHoldPendingEval_QI"
    DoCmd.OpenQuery "AlertQry6_RelFromHoldPendingEval_QM"
    DoCmd.OpenQuery "AlertQry6_RelFromHoldPendingEval_QIA"
    DoCmd.OpenQuery "AlertQry7_EvalCompleteCreditNotIssued_Initiator"
    DoCmd.OpenQuery "AlertQry7_EvalCompleteCreditNotIssued_AR"
    DoCmd.OpenQuery "AlertQry7_EvalCompleteCreditNotIssued_RSS"
    DoCmd.OpenQuery "AlertQry8_ItemsinPaintAfterPaintDueDate_2ndShiftSup"
    DoCmd.OpenQuery "AlertQry8_ItemsinPaintAfterPaintDueDate_BldgMgr"
    DoCmd.OpenQuery "AlertQry8_ItemsinPaintAfterPaintDueDate_PaintSup"
    DoCmd.OpenQuery "AlertQry8_ItemsinPaintAfterPaintDueDate_QI"
    DoCmd.OpenQuery "AlertQry9_ItemNotCompleteEvalCompletePlus5Days_QI"
    DoCmd.OpenQuery "AlertQry9_ItemNotCompleteEvalCompletePlus5Days_QM"
    DoCmd.OpenQuery "AlertQry9_ItemNotCompleteEvalCompletePlus5Days_QIA"
    DoCmd.OpenQuery "AlertQry10_ItemsOpen1WeekPostPartial_Initiator"
    DoCmd.OpenQuery "AlertQry10_ItemsOpen1WeekPostPartial_AR"
    DoCmd.OpenQuery "AlertQry11_ReceivedAwaitingEval_QI"
    DoCmd.OpenQuery "AlertQry11_ReceivedAwaitingEval_QM"
    DoCmd.OpenQuery "AlertQry11_ReceivedAwaitingEval_QIA"
    DoCmd.OpenQuery "AlertQry12_CustReceiptnotNotified_Initiator"
    DoCmd.OpenQuery "AlertQry13_RGsPending1Year_Initiator"
    DoCmd.OpenQuery "AlertQry13_RGsPending1Year_RSS"
    DoCmd.OpenQuery "AlertQry14_HoldPendingCust_Initiator"
    DoCmd.OpenQuery "AlertQry14_HoldPendingCust_QI"
    DoCmd.OpenQuery "AlertQry14_HoldPendingCust_QM"
    DoCmd.OpenQuery "AlertQry14_HoldPendingCust_RSS"
    
    DoCmd.RunSQL "Delete * from RGAlerts where RGAlertID = 0"
    DoCmd.SetWarnings True

End Function

Open in new window

0
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

PatHartmanCommented:
I think your design probably still needs some work.  As you are experiencing, saving things that can be calculated leads to problems.  One thing to consider is that if specific people are assigned specific tasks, then update only that person's data.  And don't forget the unique index suggested by Gus.
0
valmaticAuthor Commented:
I have a unique key but can't set a unique index on the column that would make a difference in this.  The record locking is a helpful tip.  That led me to a different way of doing this, maybe.  I'm closing this post.   thanks.
0
PatHartmanCommented:
You can set a unique index on any combination of up to 10 columns IN ADDITION to the primary key.  You just have to use the indexes dialog to set it because you can't do it by setting the index property on the table because that only allows you to reference a single column at a time.

There is no reason to mess with record locking.  Leave that to the database engine.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Databases

From novice to tech pro — start learning today.