I recently modified a dashboard called Part Locator.
Relevant underlying BAQ is named PartLocator.
Copied the underlying BAQ to filename PartLocatorBACKUP
Created a 2nd copy PartLocator2, in which I added a PartWhse_NonNettableQty to Display Fields, in the TopLevel query; Saved
Deleted BAQ PartLocator.
Copied PartLocator2 to “new” filename: PartLocator
Opened dashboard definition (also called PartLocator) in dashboard development editor
Tested and deployed dashboard
Closed Epicor, reopened
The updated Part Locator dashboard displayed normally, with the added Non Nettable Qty column, and its search fields behaved as designed.
I had another user test it, with the same results.
I have at least 3 users in the warehouse who report that they throw an error when they try to open Part Locator.
Because they use this dashboard a lot in the course of their daily work, I decided to roll the changes back until I find a way to update without causing problems.
Deleted BAQ PartLocator
Copied PartLocatorBACKUP to new: PartLocator
Opened dashboard dev editor
Deployed Dashboard
Closed & Reopened Epicor
Opened dashboard
Once again, the dashboard is behaving normally for me.
Same as before, but no Non Nettable Qty column.
Once again, my warehouse users are throwing the same error.
I need to figure out what is going wrong right away, because several users depend heavily on this dashboard.
I don’t understand what wrong turn I may have made. This update was one I tested thoroughly.
I noticed that the error message refers to Ice.UI.App.PartLocator_5
while this dashboard’s entry in Menu Maintenance refers to Program: Ice.UI.App.PartLocator.dll.
Could that be any kind of clue?
Or could Ice.UI.App.PartLocator_5 be just an alias - not materially different from the definition I intended to use?
EDIT:
Neither I nor the fellow in the next cube are throwing this error. Only some users downstairs.
I already checked customizations/personalizations, and there are no personal/named files to delete.
That would be the name of the deployed dashboard. Have you redeployed it since making the changes?
Also, I had deployed a dashboard once, and it created a new file with a suffix after the name. Something like Ice.UI.App.CK_ShippingSchedule_1.dll when it should have been
Ice.UI.App.CK_ShippingSchedule.dll. So obviously the dashboard wasn’t actually running the updated version.
I deployed after adding the Non Nettable Qty column to the grid.
Then I deployed after rolling back that change.
I understand that the Program: entry in Menu Maintenance indicates the dashboard definition Epicor uses to open the app. I have wondered before whether it’s possible that Menu Maintenance is not “looking” in the right place, in order to find my newly created dashboard definitions. But I wouldn’t know how to test that, to find out.
Focus on the fact that there are different versions ("_1", “_5”, etc…) of that dll being created when you deploy (make the dashboard assembly). Look at both the files on the server and on the client machine. Ideally the DLL with no suffix, should have the newest date.
The DLL with the “_1” suffix was the newest. But the menu system will use the one without any suffix (“Ice.UI.App.ck_Prod_Label.dll” in my case) - which happens to be an older version.
Look at both the files on the server and on the client machine.
I found the files on the client machine (more or less the same path as in your screen shot). They appear to be automatically versioned, as in your example.
Unfortunately, I don’t know where to find a counterpart to this folder on the server.
In principle, I think I get what you’re saying. Open up Menu Maintenance, and you’ll see the plain name of the dashboard in the definition file (e.g. Ice.UI.App.PartLocator) rather than something that’s auto-versioned up (e.g. Ice.UI.App.PartLocator_1).
Does Epicor default to versioning these definition files this way?
Can it be configured to map to the highest-numbered dll (rather than the suffix-free one) by default?
Is manually mapping to dashboard def files a necessary final step, every time (after the first time) that we deploy a dashboard?
I was curious last week, and experimented with this, to see whether I could “Browse” for a Program to use in Menu Maintenance. As you can see, the Program button is greyed out, like the text field beside it. If the selected Program Type is other than Dashboard-Assembly, then browsing is supported for the Program field.
I never got a straight answer as to whether the “_xx” suffix was an intended version control feature, or if it was some sort of bug. No one ever seems to mention that you have to update the menu maintenance after redeploying.
My guess would be that the deployment process is supposed to write over the existing DLL. But something goes awry and the best the depolyment process can do is to make the DLL file with the suffix. Some evidence supporting this theory, is the fact that there aren’t tons of DLL’s with the suffix, even though you know you’ve redeployed DB’s many times.
I think my solution was to rename the unsuffixed file as Ice.UI.App.xxxxx.BAK.DLL and change the name of the newest DLL (the whose date & time matches the XML file) by removing the suffix.
This is great insight, and I really appreciate it. If it takes me editing filenames in order for Epicor to actually find the dashboard definitions it’s looking up, then that will become a part of my dashboard deployment procedure. I want this to be as repeatable and predictable as it can be.
Right now, I’m working on finding the folder where these dashboard definitions are saved on the server side. I realize that’s a question best addressed to someone within this company. Our hardware man was at least able to help me log into the virtual machine.
Have the users close Epicor, then delete the data folder under %programdata%/Epicor on each machine.
The folder will be recreated the next time Epicor is logged into and will download from the server the correct dashboard definition. I call it Forced Clear Client Cache and find it necessary when changes to dashboards and customizations aren’t realized on a client machine…
I tried this on the computer of one of my users.
Whaddya know, it cleared the error.
Going to visit the rest of the users tomorrow, and repeat as necessary.
Realizing this is an old thread, but we had this problem today and deleting the programdata folders did not fix the issue. A previous employee had created several dashboards. Trying to edit those dashboards and redeploy caused this _x version for the dll files and associations. The odd behavior was it first only locked out everyone except the editing person but upon purging of their cache it affected them as well. After deploying, the last deployed information shown in dashboard maintenance did not show as having been updated.
The easiest fix when taking control from a previous user (and/or previous owning company) was to copy to a temporary dashboard, delete the original dashboard completely and then copy back the temporary to the original name. This method did not cause any problems with Menu references to the dashboard.
