Dangit!! caught by that logical problem again…
Ok, I’ll try that. Thanks.
Well, yeah, that too. Also if the user is launching the dashboard from a saved Favorite.
Any harm in just deleting them all? I’m guessing just a little slower load the next time is loads right?
Well, there is only one dll to pick from for that dashboard, so unless I’m missing something, I don’t think that’s it.
No, other than the aforementioned slowness the first time as they get reloaded from the server. As every environment is unique, I’d still move them somewhere safe, just in case there are issues until you know for sure.
No harm except as you noted the speed. I have users that run a batch file to delete ProgramData\Epicor on a regular basis.
I’ve noticed that despite a clear cache, a favorites and recents click pull
up the original version after changing a customization. I tend to make it
habit to remake my favorites and clear recents
2 Likes
Yeah, we’ve ran into the same issue many times too.
2 Likes
This workaround did not work. It still is getting the old one from somewhere. I had a call with support and they recreated the problem in 10.1.600.7, so hopefully they will get a fix for this soon.
1 Like
Doh! Sounds like a new “undocumented feature” of .7 patch. Hopefully a quick fix.
Hi,
I have suffered from this a lot, the only way I have found to resolve this is to copy the dashboard definition and create a new version. I intend to create mine with V1,V2 etc on the end to keep the name the same.
This will create a new dll and should resolve the issue
1 Like
I have gotten it to stick to the new one, just not with a repeatable sequence yet. I’m not sure what it takes to make the old one go away…
Perhaps look for the DLL on the app server and remove it there as well as
the workstation and then re-deploy the dashboard?
This is an old topic, but I realized that I have found and been using a workaround that works every time and I wanted it documented in here.
The cache files are found in C:\ProgramData\Epicor\epicor10-1-808\3.1.600.0\RAPAT\CustomDLLs and C:\ProgramData\Epicor\epicor10-1-808\3.1.600.0\RAPAT\shared\CustomDLLs. (at least on my computer) if I find the files that relate to the dashboard and just delete them (all all files in the folder) then it seems to be forced to go to the server to find the newest ones. This works better than clearing the cache, especially since clearing the cache gets rid of some of the hotkey settings for the user.
Thanks @Randy for the tip on that!
2 Likes
Brandon
your solution worked .
however i must note there were more directories in the SHARED area besides
C:\ProgramData\Epicor#####-e10-test-808\3.2.100.0\C001\CustomDLL
in
C:\ProgramData\Epicor#####-e10-test-808\3.2.100.0\C001\Shared\CustomDLL
which we deleted as well.
Do you happen to know - generally - how those might be used?
when we deleted them - online users got screeen errors. (resolved by logout/login)
just wondering
and thank you for the help!
1 Like
I think you can delete the whole folder, and when you log out and back in (like you mentioned) Epicor repopulates what is needed. Usually I close epicor before I delete the files, and then log back in again after I’ve deleted them. If forces epicor to pull the current version from the server. (at least that how I understand it). I usually just do a search for the .dll that I am changing and delete those, and leave the rest of it.
FYI:
I am told Development has fixed issue on ERP 10.2.200.
1 Like
One of the things that might help, is setting a value for the in your config file. I set this when I was using E9 and it made the whole blowing the cache folder away so much easier. We set it to c:\temp\epicor, made it soo much easier to to find the thing, particularly if you were on the phone to an end user.
I am wondering if part of the issue is related to security on the file-system, (Wiindows 10 and all). The ProgramData folder can display some unusual behavior at times. It may also be related to how you installed the client vs the security the user who is logged in is at the time. They may not be able to download the DLL when it is deployed and perhaps the security warning is being suppressed somehow.
Good to hear there is an SCR on the horizon though 
1 Like
Can’t resist, development must have broke it again in 10.2.300. :0
One thing you guys want to be aware of is the cache folder needs a user security that has full control over it. When we were purchased by our new company, we lost local admin rights. Along with that, Epicor started behaving weirdly until we set the user’s security permissions on the ProgramData\Epicor folder to have full control.
2 Likes