When trying to approve and check in a part we get this error:
Exception caught in: Epicor.ServiceModel
Error Detail
Message: The cast to value type ‘Guid’ failed because the materialized value is null. Either the result type’s generic parameter or the query must use a nullable type.
Program: Epicor.ServiceModel.dll
Method: ShouldRethrowNonRetryableException
We have this issue every now and again. It is due to a record(s) in the XFileAttch table that is pointing to a material sequence(s) on the method that does not truly exist on the method. Here is a LINQ query I use that shows the records from the XFileAttch table that are related to that method and ECOGroupID. I use LINQPad for this query so my connection is set to the database but this can easily be setup as a BAQ or SQL query in your tool of choice.
Key5 (from the results) is the Material Sequence – compare the material sequences from the results and see which one(s) do not exist on the method.
Using that ECO Group add the rogue material sequence(s) with any part number, does not matter, save and then remove it. This triggers Epicor to update the XFileAttch table and then you will be able to Approve and Check In the method. Actually just adding a Part Number and saving triggers the update.
In my company I think people are getting creative in the engineering workbench when they intend to shift sequences around. Instead of re-sequencing their numbers (so the attachment follows to the next sequence) they must be deleting sequence steps. In every case I have found, the operation with the attachment is still in the method but the sequence number does not match the attachment. I have the engineers change the sequence of the operation or material to ‘pick up’ the attachment, then change it back. An ugly bug to be sure. I gave them a dashboard to identify the issues with their ECO Group.
And in my case it seemed eave a little more convoluted
Where I suspect it had to do with similar changes as yuo mention
but… where theytook place in Job entry - for “on the fly” parts
And the issues only showed up later, after turning the parts into part master revisions/methods and then creating new jobs, pulling details from those methods… pukes.
In our environment it got to a point that I was tired of fixing these so I put a button on the EWB and when they hit this error I have code that fixes the issues
and they are able to check in the part.
Thanks much litzer. Info very helpful, we had ~40 bad rows in Xfileattch.
FYI for others, this issue initially presented itself with this error - Unable to process an operation sequence beyond 999 for the ‘Operation Template’ revision
Got that when using Group->Check in all.
Fixing the bad xfileattch rows, checking the revs in one at a time fixed the issue. Now Check In all works on the rev.
