We recently upgraded to 10.2.700.32 a few months ago. This version did originally fix Part Check-in performance issue. Now….we are experiencing the same performance issue we saw prior to upgrading. It takes at least 1 minute to check-in 1 part. We think that is unacceptable. My part example has a very simple MOM. We turned off BPMs but that did not have any positive results.
We run “Reorganize Index” monthly and “Full Re-index” 2 times a year. We are due to run the Full Re-index.
Does anyone have any ideas regarding this performance issue? Could it be that we just need to run Full Re-index?
Are you by chance using the same ECO groups all the time? In a past life, that’s what we did, was this person just used his/her ECO group. However, when you check in parts, the system doesn’t delete the rows from the ECO tables. They just marked them checked in. Because of that, the system loops through more and more data as the group is used. So you’ll have to occasionally change groups to get past this… erm… bug? Unintended consequence either way, bug or not.
Thanks Brandon! My test was with a brand new ECO group and still had issues. But I will still make sure our Engineers understand that quirky functionality.
I remember we had similar issues with performance but that was back in Epicor 9 and it was all good after the upgrade to 10. Make sure you’re updating the statistics as well when you do the reindex.
There’s a data fix you can request that removes checked-in parts from the ECO tables. Apparently they intend the ECO tables to be some kind of half-assed rev history record, but it only works if you’ve popping out a new ECO group for every change you want to track.
Fix is called FX_Del_ECORev_byGroup and Epicor will pepper you with “are you really sure you want this?” questions. Running it nuked over 2 million rows from our DB across the various ECO tables and Workbench perked up noticeably.