Server side caching?

I’m still trying to resolve an “intermittent” customized purchase advisor problem. Before I threw up my hands and walked away yesterday, I reproduced the problem dozens of times when launching the form by choosing the customization while in developer mode. I actually got to a point where I had all lines of executable code commented and all BPMs and Data Directives turned off. Consistently threw the same application error anyway.

This morning, I didn’t change a thing - cleared no local cache, opened the form the same way and no error.

It acts as if it’s pulling the customization from a cache on the server as opposed to getting the latest and greatest out of the database.

Is there such a thing as a server-side customization cache?

Hey Joe,

Not sure if it would help, but @aidacra mentioned at Insights and in a recently in an EUG meeting that many caching issues can be solved by using an alternate client cache folder. In your local .sysconfig folder in the appSettings section, find the key:

<AlternateCacheFolder value="" />

Create a folder and set its location here. It’s best to use %username% in the path - ESPECIALLY if you’re using a terminal server!

So maybe this might help.

1 Like

In Epicor9 we used to leave the Customization Name alone:

XYZ_Customer_Entry

In Epicor10 due to caching issues we version the Customization Name:

XYZ_Customer_Entry_yy.mm.dd

Which resolved the Caching Issues, but Personalizations are lost and you have to re-target it on all Menu’s who still might be pointing to the old version. Its a Pain, but only way to resolve it.

I might have to try what Mark said, havent tried that yet.

1 Like

Hi Mark,
Thanks a lot for the suggestion. Unfortunately it didn’t help in this instance, but I’m glad to be aware of it!

Once the error strikes the Purchase Advisor form, if I don’t clear cache before running the base version, the same error shows up. Something seems stuck somewhere. This is with BPMs and DDs off. Weird!

Joe

How are you clearing the cache? The only good way I have found is if you close Epicor and then go to C:\ProgramData\Epicor and delete the folder.

Never got the “Clear Cache” function within Epicor to work.

Thanks for the idea, Haso. It’s a great idea, but our menu administrator would hurt me.

Yes, exactly. Wiping out Epicor directories under ProgramData.

What I do when I package the .cab is I write Instructions and a SQL Script.

2019-05-14_1310
2019-05-14_1312

-- Update Part Entry and Part Display
UPDATE Ice.Menu SET Arguments = '-c Part_Entry_19.1.24' WHERE MenuID IN
(
	-- Part Display (These are actual Part Entry's under a weird name)
	'IMGO3410',
	'SVTK1076',

	-- Part Entry
	'FSMT2000',
	'PHMN1040',
	'PMMT1002',
	'QAMN0150',
	'RQMT1020',
	'SEMN1010',
	'IMMT1102',
	'JCMT1020',
	'MRMT1010',
	'OMMT1112'
);

-- Update Part Tracker
UPDATE Ice.Menu SET Arguments = '-c Part_Tracker_19.1.24' WHERE MenuID IN
(
	'CRMG1140',
	'EQMT2050',
	'ESGO1002',
	'FSGO1450',
	'IMGO3002',
	'JCGO3005',
	'MRGO2040',
	'OMGO3004',
	'PHGO1080',
	'PMGO2003',
	'QAGO1030',
	'RQGO2060',
	'SEMN3010',
	'SRGO1006',
	'SVGO0013'
);


-- Validation of Part Entry and Part Display
SELECT * FROM Ice.Menu WHERE MenuID IN 
(
	-- Part Display (These are actual Part Entry's under a weird name)
	'IMGO3410',
	'SVTK1076',

	-- Part Entry
	'FSMT2000',
	'PHMN1040',
	'PMMT1002',
	'QAMN0150',
	'RQMT1020',
	'SEMN1010',
	'IMMT1102',
	'JCMT1020',
	'MRMT1010',
	'OMMT1112'
);

-- Validation of Part Tracker
SELECT * FROM Ice.Menu WHERE MenuID IN 
(
	'CRMG1140',
	'EQMT2050',
	'ESGO1002',
	'FSGO1450',
	'IMGO3002',
	'JCGO3005',
	'MRGO2040',
	'OMGO3004',
	'PHGO1080',
	'PMGO2003',
	'QAGO1030',
	'RQGO2060',
	'SEMN3010',
	'SRGO1006',
	'SVGO0013'
);

That’s a great trick. I’m used to averting my eyes when I see data being updated directly. Is this approach blessed by Epicor?

Epicor prefers you go to Menu Maintenance and Update every Menu spending 1hr :slight_smile: and miss a few.

I only do it for harmless columns - Arguments Column, Description, CommentText – but beyond that I dont do anything more crazy. You could also if you feel more comfortable probably make a DMT Template.

In our Company the DEVs don’t have access to Production… so we Deploy from DEV to TST and write the manual on how to Deploy with Screenshots… Infrastructure then deploys it to PRD.

But you can also see I target the ID’s Specifically… I dont just say UPDATE where Name = ‘Part’ because that would hit HandHeld Menus as well.

I typically do that for Updates, when its a new Menu Item I can Export it via Solution Workbench.

There is always a “Validation” Step for the Analysts to Make sure it all works and rollback plan, so they dont call me at 10pm – just back out.

UNLESS Epicor Fixed where you can re-deploy a Menu via .cab and it will update it… In 10.1.500 it threw errors because It tried to add the Menu, not Add/Update.

1 Like