We just upgraded this past weekend from 10.1.400.37 to 10.2.300.8 and so far it has been an excellent experience. One little thing I am seeing much more of is the Row Has Been Modified garbage. Normally it was just my shippers who saw this now I see it in Customization Maint. Is there any way to stop this for all of us?
Interesting - I havent seen anything yet. I am planning to go to .9 on Saturday (it should come out tomorrow). Curious to know if others have seen this too.
We saw it in 10.1.400 but were hoping it would be fixed by now. My shippers have not liked this issue for a long time and I have never found a way to stop the issue from happening. So here we are hoping that by now someone has figured something out.
It may be some of your custom code? We used 400 and 500 like crazy. BPMs, Service Connect, Customizations etc… Especially UpdateExt() can cause alot of it.
We have some customization’s, several BPM’s, but nothing big. I was reading that keeping SysRevID from being passed would fix the issue. Not sure if that is true or even how to do that. Do you know if that is true?
This is fairly common with BPMs and or Customizations that do not account for data (front end) refreshes. Is this there customized screen or BPM at all involved?
Do you have any of these BPMs which run in Post-Processing?
Yes, it does have a customization.
Any of the BPMS running on Post Processing? in any of the related methods?
Yes, some are Post Processing, actually. One of the Post is an BPM for the Sales Order, SHipTo, OrderJobWiz,and Job Entry.
For a bit more indepth information. This error happens when the SysRevID in the loaded record doesn’t match the SysRevID in the Database. That is when the record on the screen is “older” than the record in the DB.
When a change is made to the record, the SysRevID field is automatically updated and this is compared before an Update() with the existing record on the screen. If these values do not match that means that something or someone updated that record and didn’t refresh the screen.
This typically happens on a BPM or Data Directive which runs in Post Processing, becasue the record changes and that change isn’t propagated to the screen properly.
It can also happen if you have Updatable Dashboards which modify or touch one of these records. You can be in the Order with a record loaded and someone / somewhere else will uddate that record via the UBAQ and modify your RevID.
Anything that Runs in Post Processing and modifies a record, needs to make sure that the record being returned in the ttTable is also updated to the “right” version.
This is usually done by running GetByID() after the code has ran, to “refresh” the ttRecord.
Gotcha. So is there a way to stop this from happening, or is this just the cost of customization?
You need to refresh your record after the post processing BPM happens. For example if you have a Post Processing BPM on SalesOrder.Update() which changes the value of say a field in order head… your Workflow should look something like this
PostProcessing BPM
Update Record
Run Get By ID on SalesOrder to Refresh ttRecord before it is sent back to the screen
here is an example of how to do that, for a Quote but the same principle applies
Epicor makes use of Entity Framework and MS SQL ROWNUM Column. We use the same in our Custom Applications… What if 2 Clients connect to X Database and both people modify the same record… Well who ever hits save first wins, the other person - has to refresh and retry.
Entity Framework can handle the lookup by itself and throw an Exception.
It doesnt matter who updates the record… Even i I were to do Direct SQL UPDATE the ROWNUM will increment (change) (SysRevID) and then when your User tries to save, it will say “you simply have an old record, cant do it!”
we are on 10.2.300.8 and have not seen this.
I always thought it was when you try to do something that someone else may have touched first or when I was doing stuff just got out of sync and clicked refresh…at least in past experience.
Ok, so in the customization I need to add code to refresh the record, correct?
no in the BPM
@Will79 - There were some issues with this when viewing verify results in Customization Maintenance.
I’m seeing it often in our 10.2.xxx.x testing… Not sure if it’s been fixed. Feel free to pop in an EpicCare case assigned to Technical. They’ll explain it better than I could.