However, this morning a user who has been having this same issue daily since Sunday’s update had the issue happen again.
Overnight Epicor sent me another message saying in addition to clearing cache to try changing the client *.sysconfig setting for MaxBOMRU and MaxClssAttrMRU to zero in addition to stating that their dev and support teams are still investigating this issue and are just trying to provide workarounds right now. I haven’t tried changing the client *.sysconfig setting for MaxBOMRU and MaxClssAttrMRU to zero yet. Has anyone tried this and seen it fix the actual issue for good?
It may not be the same, but it wouldn’t be the first time the same new bug was introduced across multiple versions. We didn’t have the issue with 2023.2.24 and earlier, just after we bumped to .29. I dropped a batch file on the most affected users desktops that clears all three cache locations so they could self-fix.
I’m going to look into the MaxBOMRU and MaxClssAttrMRU settings for us, but with the holidays I doubt I’ll get any data points for a while.
Just adding what might be a titbit. 2 users running Epicor clients on their laptops were asked to update their passwords. 1 running windows 11 needs to have Epicor reinstalled. 2nd running windows 10 pro was able to log in after 15 min timeout for forgetting password…
The commonality being password expiration.
Just checked with 3rd user. Epicor could open… go figure.
We seem to attract all the bugs, so the fact that we’re not being hit by this issue is telling. I may have some information that could help.
Starting 3+ years ago, on the Epicor-hosted cloud, we would get random Business Layer Exceptions on all pages (including home), processes would get stuck and wouldn’t unstick, the perpetual login wheel daily…all of it. Support could not/would not figure it out, so I complained and complained and complained until I got more senior analysts looking at the problems…and what they discovered was the Collaborate connection was failing, and that in turn was hosing up communications everywhere. Once we completely stopped/removed Collaborate, most of the big issues went away. It had something to do with the Synergy service…I can’t quite remember, but it was a service that was (I believe) intended to keep authentication between different services in sync.
Anyway, my point is…check your logs and check Collaborate. This is the type of error we were seeing: ***<Op Utc="2024-09-03T11:49:28.9475490Z" act="Ice:LIB:Synergy/SynergySvcContract/GetAvailableGroups" correlationId="0c18e785-a93d-43a9-ad2b-ce32c2dc495e" dur="13.9924" cli="10.43.1.xxxx:1111" usr="jacob" machine="LVxxxxxx" pid="18428" tid="88">*** ***<Exception><![CDATA[Ice.Common.DataValidationException: Invalid SysConfig data. There is no SynergyId.***
Collaborate was updated on 12/15 - the same day/day after the 2024.2 upgrade. Just saying…
Not a fix but a workaround I have been using is having them sign in to an account that is working, for me its a generic shop floor account, once their signed into that they go to settings and click change user, type in their user info and it will load.
For the record, we just added the clear cache batch file I mentioned here to all our computers Startup folder and a shortcut to their desktop. We’ve not had any tickets about it since.
I understand, but those settings correlate to two different xml files in the cache. In our testing, moving the BOMRU file does not solve the problem. Only the class file has to be moved. So that would seem to indicate that only the class setting is relevant.