Run a task Exclusivly (1 Viewer)

[PNGBill]

Ms Access 2010 accdb.
We have a Function that loops through records and identifies where a Late Fee May Be Charged.
I want to change this slightly so it appends records to tblBulkLateFees and then the operator will review a Continuous Form clicking where No Late Fee should be charged this time (maybe 10 out of 200 records) and then the Late Fees will be actioned from tblBulkLateFees.

What I fear is that while this process is taking place, another operator may charge a Late Fee or do some other activity to a record that may make the data on tblBulkLateFees out of date

How is this approached ?? Of course if an operator was to start the process and take a Late Lunch before reviewing the continuous form, then you could hardly expect time to stop. We don't have many operators so we could just call out let all parties know but this doesn't sound like a Text Book approach

Appreciate any advice.

Cuurently the process is to handle each record and make the choice and go onto the next. This virtually means no chance of a record change but it means an operator must remain working on the task for long time where as the new process just means a quick review of the form and the system will sort out the charging of fees and sending an email message.

 

[sparks80]

Hi,

Have a look at the following URL, this will hopefully help you to understand record locking:
http://www.databasedev.co.uk/multi-user-application-record-locking.html

Go to the property sheet for the userform where you are editing these records. Go to the data tab and scroll down to Record Locks. Now select "All Records".

Now when another user tries to edit the record they will be presented with a dialog asking them to save changes, copy to clipboard or abandon changes.

This is quite a pessimistic way of locking records, so you would not want to do this as a general rule. Often it will suffice to lock just the specific record being edited.

 

[PNGBill]

Thanks sparks80, I beter read up on Record Locking.
The issue is also more what process to use ie. The tblBulkLateFees can be locked, as your post, but this will only prevent another operator from running Bulk Late Fees.

There can be invidual Late Fees calculated for a record and what if another operator is entering a Repayment while the Bulk operator is reviewing the SnapShot that indicates no repayment has been made.

The current system, while termed Bulk, actually reviews each record one at a time therefore any changes made would be picked up in each operators activity. ie If the curent Bulk process came across a record that had just had a repayment made or Late Fee added (10 secs ago) then suitable action would be taken, where as with my proposed SnapShot tblBulkLateFees process I may be 20 mins out of date .

How is this addressed in bigger systems ?

To address all activities would involve locking a few tables and stopping tasks being done that may have no impact on the Late Fee issue ?

 

[sparks80]

I think I may be out of my depth to answer you're question in detail, maybe somebody else can jump in here?

I do know that the form record locking affects the underlying record source, rather than any one specific table. Not sure if this helps, but if the form is based on a query that links several tables, then they will all be locked by this mechanism.

You are right that this is not ideal, as it will likely prevent other users from performing their tasks.

 

[PNGBill]

Thanks again, good to have your input. The issue is also very much a work place procedure.
Maybe a task best done in quiet times/afterhours ?

Or some other method ?

I could build in a last check to confirm a Balance and throw an alert if there was a change between the SnapShot balance and the Balance just before the Record was to be actioned.

While this would mean the Bulk process would stop, it would be a rare occurrence. Or maybe just return to the Continuous Form with a message regarding any Records that could not be actioned due to a Data difference while the task was being handled.
Maybe the system could re evaluate these records and return a message if there was a change in the outcome but if no change then either charge the fee or not as intended and as the current data would suggest.

I think I can proceed following my Rambling above