Clear Client Cache not working

(Randy) #1

Clearing my client cache isn’t working. I have full control over the folder C:\ProgramData\Epicor. This is causing my BAQs to mess up in BAQ designer.

(Chris Conn) #2

You are gonna need some more details here.

(Heather Marie) #4

If you close out of Epicor completely on your computer and then actually go to the C:\ProgramData\Epicor\erpservername-808 (for example) folder, can you rename it? If so, can you get back into Epicor and see if that fixed your BAQ problem? If not, maybe something is locked in the folder and that’s why your Clear Client Cache seems to not be working?

(Randy) #5

I think we fixed it.

(Nathan your friendly neighborhood Support Engineer) #6

What was the solution?

(Randy) #7

Well not so sure. We changed some folder permissions and it worked for awhile, then not. Today has been fine.

(Kevin Krumwiede) #8

I’m randomly running into this problem as well in I recently deployed a change to a UI form and a related change to a BAQ as part of the same solution. For some users it works automatically. For others it works after clearing their client cache. And for a few it does not work even after clearing their cache and restarting Epicor. They’re stuck with the old version of the form that tries to access a BAQ column that no longer exists.

(Jose C Gomez) #9

Sometimes you have to blow away the whole C:\ProgramData\Epicor<YourAppServer>
folder. Are they using Terminal Server to access? If so I recommend going to split caches (unique per user)

(Kevin Krumwiede) #10

Whatever the workaround, this is a scary issue. What if my change to the BAQ hadn’t broken the old UI form? Users could conceivably be saving incorrect data, blissfully unaware.

IMO, the client should refuse to run if it’s unable to clear its cache. And since some users habitually leave the client running all week, it might even be helpful to disable the cache.

(Randy) #11

Clearing the cache works, but some days it happens frequently. I am told by Epicor it’s a known bug and a fix is in the works.

2018-10-11 08:01:18 -Frank DiCarlo

Good news! Development has assigned an Update for your fix:

The Fix Version/s for Update Request ERPS-100288 has been set to 3.1.600.32

(Carson Ripple) #12

Here’s what I’ve seen with clearing cache:
Deleting C:\ProgramData\Epicor\YourAppServer always works.

When you try to clear the cache using the UI you should clear the cache after restarting Epicor and before opening any screens.

Here’s what I found while watching the C:\ProgramData\Epicor\YourAppServer direcotry while clearing the cache. (10.1.600)
Say you open a dashboard and get the old version, so you clear the client cache through the UI.
This deletes everything in C:\ProgramData\Epicor\YourAppServer except the file for the dashboard you just opened. Now you reopen the dashboard and it opens correctly.
Epicor got a new version of the cache file and placed it in C:\ProgramData\Epicor\YourAppServer, now you have 2 versions of the cache file, but this session is using the new one and everything looks fixed.
But the problem is when you restart Epicor and open the dashboard again it uses the old cache file and the old dashboard loads. This can lead to a never ending cycle.

Open the dashboard - the old dashboard loads.
Clear the cache - the new dashboard loads.
Restart Epicor.
Open the dashboard - the old dashboard loads.
Clear the cache - the new dashboard loads.

When ever I make an update to a customization I always update the customization ID. This eliminates and cache issues with old customizations being pulled.

(Kevin Krumwiede) #13

That’s exactly what I just discovered. One of the users for whom clearing the cache seemed to work last week had the old version of the form resurrected on Monday morning.

For our installation at least, there is no perceptible difference in load time when opening a form for the first time after deleting the cache directory. The cache seems to be a pointless source of trouble.

(Randy) #14

Development has completed the fix in 10.1.600.32
It will be out on EpicWeb on November 15th.