Pre checks for "Data was changed by another user"

An option should exist to allow forms to do background checks if the records selected have been changed by another user.

Either show a pop-up, or an indicator on the toolbar. That way a user won’t spend time entering data, only to be told they can’t save it because the data on the server has been changed. The user then has to refresh the current record(s) - losing any changes they entered - and then have to re-enter them.

Consider making the option:

  • Global - all users, all forms
  • Form specific - can be enabled on a form by form basis
  • User specific - applied like personalizations

The way Epicor does it, is the same many of us do it, most of it is done by Entity Framework. The only way for them to do that is to ping the database row every X seconds and see if SysRevID != (Active SysRevID). One thing to note this behaviour can be seen across 100s of apps, it has become the norm to use ROWVERSION, we even do it in our internal apps. Maybe its just the nature of the beast and Microsoft needs to add something to EF to make it easier to get pre-status.

SysRevID (ROWVERSION) is handled by SQL so even if you made a direct sql update, it would increment it.

Just thought I add some info, in case someone ever wondered what SysRevID is and does.

Probably easier said than done :slight_smile:

Perhaps the easiest thing for Epicor to do is to Mark the Row as Locked (Checked Out by X User) so others cant edit it concurrently. Just like a Invoice Group – then of course it should also timeout the lock if the user who was editing simply used CTRL+ALT+DELETE to kill Epicor.

In either case, we have a large concurrency usage and it doesnt happen often, and when it does its just the highlight of the people in the Purchasing or Sales Department not communicating amongs themselves, or Jerry decides to do something he shouldnt be doing anyways :smiley:


Makes sense …

Now how about making it so the notice that the record has changed, has a refresh option, so I can dismiss the pop-up and have the form reload the new data automatically.


1 Like

I’ve gone down this path across so many products, it’s an interesting pattern at an architectural level. I started in the industry with an Event Source based model for updates (long before Gang of Four and patterns were slapping labels on solution approaches). I’ve always liked a time based approach to updates to minimize conflicts on updates.

In general, if you have a full pessimistic locking based approach to data updates you are going to crawl your system to a halt. That pattern has been discredited heavily at the lowest levels due to the performance and usability concerns in the opposite direction - trying to edit a record ‘locked’. Also, with distributed and sync oriented systems, good luck trying to manage locked records when you are dealing with remote devices like a cell phone or browser and it goes poof on the network without cleaning up locked records. How long before you unlock automatically? And that background auto unlock is not free as it scans things constantly.

The best approach I have seen to manage specific areas, critical forms is not hard to implement with UD fields.
Add a new field for who locked record - the username, the time. Then on query, if the time is too long ago (5 minutes? an hour? - this is where it gets hard), the record is treated as locked in the UI by a client customization. The form goes read only with an indicator that Bob in Accounting has locked the record ‘x’ minutes ago.
If the time has elapsed, the record is not locked in the UX. Then User #2 can update the record and when Bob is back from lunch, they get the optimistic locking error - so you can never eliminate it.
Also, if set to say an hour, how do you override the lock and free the record? You’ll need additional record for admins or the like to unlock a record when someone steps out for a coffee so prepare to have admins buried with phone calls.

I would not implement across the whole system but if you feel you need a specific form you could try this. If this is a UD table(s), I’d also heavily recommend looking at decomposing the table structure as much as possible to minimize normalization. The smaller the table, the less likely you get contention fighting over a record.