Error for one user sometimes


(Brandon Anderson) #1

So I have one user (and only one) who get’s and error sometimes when opening part entry from the order entry screen (right click open with). Once she gets this error, upon opening part entry, the tree is always empty and the tool bars on the top are gone. Then, any time she opens part entry, it doesn’t work right. If she closes epicor, then restarts is works fine for a while. We can’t get it to mess up on demand, we think we are going through the same steps, but then it will work fine. I have deleted her customization, deleted her shortcut, but the problem still pops up. I tried opening her personalization on order entry, and right click open with for part entry, again with her personalizaiton, but I can’t get it to screw up.

Below is the error that shows up when it has the error. I can’t tell what the issue is with it. Anyone have any ideas? The part entry screen is only lightly modified. A couple of added fields bound to extended UD fields is it. The order entry screen being customizes to create contracts and contract bins. I don’t think it has to do with that.

 **Application Error**

Exception caught in: mscorlib

**Error Detail**


**Message:** Exception has been thrown by the target of an invocation.

**Inner Exception Message:** Object reference not set to an instance of an object.

**Program:** CommonLanguageRuntimeLibrary

**Method:** InvokeMethod

**Client Stack Trace**


at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)

at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)

at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

at Ice.Lib.Customization.CustomScriptMethodInvoker.InvokeScriptMethod(MethodInfo scriptMethod, Object[] parameters)

at Ice.Lib.Customization.CustomScriptMethodInvoker.InvokeInitializeGlobalVariables(CustomScriptManager customScriptManager)

at Ice.Lib.Customization.CustomScriptManager.<InitializeCustomAssembly>b__116_0()

at Ice.Lib.Customization.CustomScriptManager.TryActionShowExceptionBoxIfException(Action action, String exceptionBoxTitle)

**Inner Exception**


Object reference not set to an instance of an object.

at Script.InitializeGlobalVariables(CustomScriptManager csm)

(Mark Wonsil) #2

Corrupt personalization?

(Haso Keric) #3

I’ve seen that mscorlib with Personalization Issues, typically when customizing grids or the Search Window Grid that ships with a Form

(Joshua Giese) #4

Agreed we usually clear personalizations and that goes away. We have one user that same thing Sales Order Entry about once a week for a while there we had to delete his personalization. It comes and goes in waves.

Step 1, if you implement new, never let anyone know personalizations exist and never ever enable them.
Step 2 Enjoy life.

hmm… maybe “Epicor” will “get rid” of personalization in 10.2.300 muah ha ha ha ha ha :wink: :wink:

(Haso Keric) #5

They are to fragile anyways and if you change your customization name from XYZ_1 to XYZ_2 personalizations are gone. But if you don’t then Caching tends to not show your users the new changes. We can’t win :slight_smile:

(Brandon Anderson) #6

I have deleted the personalization. However, maybe I can try deleting that then clearing caches and start over and see if it’s something there.

(Kevin Krumwiede) #7

This sounds like the known issue with clearing caches. Clearing the client cache does not actually clear the client cache. I’m not sure what it does, exactly, but old versions of forms still linger in the cache, and will get reloaded at seemingly random times. Even without restarting Epicor! I ran into this recently with Part. Open Part, everything’s fine. Close it. Open it again, get the old version. I could tell it was the old version because it was trying to access a BAQ field that I had removed.

The solution is to delete the entire cache directory. On every single client. And make sure all your changes to forms are non-backward-compatible so they’re fail fast the next time this issue rears its ugly head.

(Nancy Hoyt) #8

Hi Brandon,

I have found that using developer mode and going into customization that way and deleting Personalization there does not always work. After doing that, I recommend (if you haven’t done so already) go to customization maintenance, search for personalizations by the person and then bring it up and delete it there in customization maintenance, if it still exists.

BTW, we cannot personalize quote entry at all on top of our customization or we eventually get this error on a user. Company rule: thou shalt not personalize quote entry… very robust fix :slight_smile:


(Valentina Busti) #9

Is there a way to transport those personalizations to the new version?
I am new to this side of Epicor and I am too blind to see the solution.

(Brandon Anderson) #10

There is not, unfortunately. That’s part of the pro’s and cons to doing the customizations with updated version numbers, or overwriting the original one.

Personally, I save out a copy before making changes, then make the changes on the original in the system to that people get to keep their customizations. If something get’s messed up, I have a backup to revert to.

(Haso Keric) #11

Same I usually never used versioning. I version out of the system in git, VSTS etc… but in E10 the cache doesnt play nice if you don’t version. So you could teach your users to clear their cache or store it on a UNC path then you have control over cache.