Did Microsoft Break Something?

Epicor ERP 10
1

Hello,
I have a bunch of BPM code laying around in production that we’ve had there for years. All of the sudden this week from multiple customers we are getting the following error

Error Detail 
============
Description:  BPM runtime caught an unexpected exception of 'NotSupportedException' type.
See more info in the Inner Exception section of Exception Details.
Program:  EntityFramework.dll
Method:  Translate
Original Exception Type:  NotSupportedException
Framework Method:  A001_CustomCodeAction
Framework Line Number:  0
Framework Column Number:  0
Framework Source:  A001_CustomCodeAction at offset 1718 in file:line:column <filename unknown>:0:0

Now this particular error is fairly common in LINQ statements if you do something that EF can’t translate to SQL. Chiefly being calling .ToString() inside of a LINQ statement.
However this isn’t the issue any longer. Take for example this piece of code, it has been in production for over a year and this customer has not updated Epicor… (though they do update Windows/Microsoft)

Original Code

//Other stuff here 
var orderHed= (from oh in Db.OrderHed 
				where oh.Company == callContextClient.CurrentCompany && 
				oh.OrderNum == ttOrderHed[0].OrderNum select oh).FirstOrDefault();
//More Stuff

The “gripe” is that bit ttOrderHed[0].OrderNum it is claiming this is not supported, however this code has been running in production for over a year. The fix is easy, I just assign the order num to a local var and pass it in to the LINQ query

int orderNum = ttOrderHed[0].OrderNum;
var orderHed= (from oh in Db.OrderHed 
				where oh.Company == callContextClient.CurrentCompany && 
				oh.OrderNum == orderNum select oh).FirstOrDefault();

and this fixes the issue, but there have been no changes to Epicor… this is a Microsoft “break” as far as I can tell. Has anyone else seen this? Another good one is using the string.Equals in LINQ. Again it appears that for some reason they are no longer supporting

string.Equals(x,y,StringComparison.OrdinalIgnoreCase);

However the other overload without the case sensitive check works fine

string.Equals(x,y)

I feel like I’m losing my mind, has anyone else seen this?

1 Like
2

Ask @Bart_Elia, i think he bumps shoulders with those guys sometimes

1 Like
3

I am not sure the MSFT folks think I am bumping shoulders with them as much as beating their shoulders with a nerf bat.

@josecgomez did the customer upgrade .net versions any chance?

2 Likes
4

I don’t think so… (but maybe) they do run Microsoft Updates… this has happened on at least 3 customers this week specifically…

1 Like
5

May we suggest you use something more firm? :wink:

3 Likes
6

OK, looks like two things here…

First, the queries above changing

where oh.Company == callContextClient.CurrentCompany
&& oh.OrderNum == ttOrderHed[0].OrderNum select oh

to

where oh.Company == callContextClient.CurrentCompany
&& oh.OrderNum == orderNum select oh)

doesn’t make any sense so I’d like a repro snippet- version of the system and dotnet version very much needed please.

The string overload is a second question and I am not sure how that ties in if at all to the first. If it’s a larger snippet, what’s the context?

1 Like
7

Right so the first sample is the original query (causing the exception) the second is the “fix” which is to pull the orderNum into a var.
I’ll send a better example.

2 Likes
8

I suggested (via DM) to try this…

var orderNums = new int[1] {ttOrderHed[0].OrderNum};

. . .

where oh.Company == callContextClient.CurrentCompany

&& oh.OrderNum == orderNums[0].OrderNum select oh

Is the query in an external assembly or typed directly into BPM? If it’s the latter, we might just want to double check the BPM directive code assembler isn’t getting tripped up on anything (like dropping an ampersand). Also, did anything change with the definition of the ttOrderHed type?

1 Like
9

I feel like I’ve had that before when creating stuff – I ended up having to put it into a variable first like you showed.