Slight change to dashboard; some users throwing invocation error - Epicor ERP 10

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

相关文章推荐

直爽的哑铃 · Getting error in ...· 5 天前 ·

逆袭的饭盒 · Slight change to ...· 1 周前 ·

刚分手的肉夹馍 · cross-cloud/.gitlab-ci ...· 2 周前 ·

低调的打火机 · Work with query ...· 3 周前 ·

玩滑板的野马 · 标准版更新记录 | MoChat· 4 周前 ·

闷骚的黑框眼镜 · Talend· 15 小时前 ·

内向的花卷 · 學術知識服務網 - 慈濟功德會創辦人是誰?· 5 天前 ·

近视的茶壶 · 飞“5”大湾区｜重大项目“满弓”推进！大湾区 ...· 1 月前 ·

慷慨大方的脸盆 · 魏建军“动刀”营销，长城任命多名高管_手机新浪网· 2 月前 ·

傲视众生的鼠标垫 · 快活视频app污-快活视频app污无广告版a ...· 7 月前 ·

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.

0712 Exception thrown Mark 1476×885 36 KB

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.

see also:

Dashboard doesn't display column in test mode or when deployed ERP 10 I’ve run into deployed dashboards not showing the latest, and found some “duplicate” DLL’s created. The newest ones had a suffix like _0 or _1 added to them. But since the program is looking for Ice.UI.App.MyDashboardID.dll and not Ice.UI.App.MyDashboardID_0.dll it’s loading the "deployed prior version. To test if this is your case, change the title of a pane or grid, and then see if the new title shows when you use the Test Mode in the Deploy window. For example: [image] The dashboar…

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.

Here’s something I had a longtime ago:

image 742×257 15.2 KB

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.

In other words:

Ice.UI.App.PartLocator.dll -> Ice.UI.App.PartLocator.BAK.dll
Ice.UI.App.PartLocator_5.dll -> Ice.UI.App.PartLocator.dll
              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…
image808×273 22 KB
              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.