Our client computers throw this error and the entire ERP system goes offline multiple times a day: An EdmType cannot be mapped to CLR classes multiple times.
The only way we can get the system back online is to recycle the application pool through IIS. It will get the users in the system, but it keeps happening, seemingly randomly.
We have tried implementing the known “workaround” for version 10.1.400.20 as this seems to be a known bug. However, removing the two dll files did not seem to stop this error from returning / taking down the ERP system ("Epicor is offline) throughout the day yesterday.
Our current thought process is that maybe there is a function, report, task, command, etc…that might be triggering the system failure, but we are not able to pin point what that might be.
We do not yet have the luxury to upgrade our version at this time due to 3rd party software / module / customization that relies on this current version. Not the mention the time it takes to properly go through testing phases of processes / production within the newer versions before going live within them.
We have a ticket open with Epicor currently on this, but there seems to be a lack of urgency on their end trying to figure this out and get back to a stable environment.
There was a threading issue we found in Entity Framework some time ago and did a workaround for in an earlier release and patched it in many versions. Contact Support with that description and they can pull up the ticket and review your version vs versions where it was fixed.
< Geek Background >
The issue was when multiple clients were calling into the server and it was instantiating EF twice. There was a process in EF that was not thread safe and when EF was going through it’s internal mapping standup - it ran into the issue - trying to map the ‘physical db model’ to the ‘logical db model’. Many time this error will indicate ‘ABCCode’ as it’s the first table alphabetically to be loaded.
Solution? Lock the ‘new EF()’ functionality to prevent two clients doing it at the same time.
< / >
Thank you! - If I were to provide you with the case number would you be able to supply the patch directly in the case for us? Either that or could you provide the SRC number?
It should be fixed on 10.1, it was an issue on 10.0, support can only send fixes on tht version. We have a customer here who report this sometime, but not daily. SCR 155400
aidacra
(Nathan your friendly neighborhood Support Engineer)
6
There were a couple different software causes to the EDMType issue, depending on the version:
10.0.700.x: SCR 155400 (retro’s available for 700.4 and 700.2) <-- this is the issue that @Bart_Elia expanded on earlier today.
10.1.400.21 and earlier / 10.1.500.6 and earlier - SCR 193409. Way to get it? Upgrade to 10.1.400.22+/10.1.500.7+.
I thought by deleting those dll’s mentioned in SCR 193409 was supposed to fix this for us. I even read on a different post related to this same message that they were still experiencing the EDMType issue until upgrading to .28.
What a mess. Where do we even go next? We simply cannot upgrade at this time. There has to be another solution.
Please advise.
aidacra
(Nathan your friendly neighborhood Support Engineer)
8
Please relay this and any other information you wish Support to know through the open case you have.
There are always business cases to be made on your scenario. The default is to always apply a fix to the rolling patches. We are not perfect but have done a ton to make the patching more stable and I hope to continue that with more internal efforts. The old way of doing a hotfix for everything is just too danged fragile - you all told us that which is why we went to the rolling fixes.
You get a patch on x
You get a patch on y
x is broken because y overwrote x
You needed get an xy patch and while doing that for one or two items, when you get into the complexity of many subsystems and many customers… Let’s just say the patching process is a heck of a lot more stable and faster to get a solution to you than that.
But we are not (completely) cold and heartless. We have done some special cases but you need to do the justification and explanation and accept the consequences. We could reintroduce a bug on another patch or an upgrade and then you are back at square one. As I mentioned before, we did a lot of work on the patching process due to customer feedback. It’s worked overall and many up here have commented on more stable upgrades due to that.
I hope that explains the what and why. As always, we do listen
The other thing that I would point out Jim is that actually going from point release to point release is painless and shouldn’t break anything. If you went from 10.1.x to 10.2.x then you have to test all of your business functions and processes to ensure they work.
I personally have not had any issue when simply apply an update such as 10.1.400.16 to 10.1.400.18 etc. If you’re having that much problem with your system as it stands today, then take the hit on doing the point update to get onto one of the versions that Nathan says has the fix baked into it.
