During our nightly MRP process set, there are thousands of ‘informational’ messages in the server log and Application Event Viewer that all say “Cancelling from .ctor”. MRP, and Global Scheduling finish without error, and everything seems to have been calculated correctly, and no errors are reported in the MRP logs. These messages have been occurring for quite a while, but now I would like to understand what they mean, and possibly how to stop them.
Anyone know what these messages mean?
Andrew Lintz
Did you ever get to the bottom of this Andrew? I noticed the same thing today and a search brought me here.
Nope. Still getting thousands a day.
Epicor Support’s only comment to my case was 'it is just an “informational message” and is not an “error” ’ (as if that was something I couldn’t read for myself).
I see an error in the Server Log: “Value Cannot be Null” that seems to be related to Cash Receipt that seems to happen at the same time as the ctor error, I think.
While it may not solve it, a bool cannot be null. A nullable type can Nullable but a bool is either true or false. So as the serialization process attempts to serialize the bool value for CheckBox01, it cannot because the value is null.
Andrew - the errors all seem to be related to the Extended UD columns. From the name of the column - PbsCompleted_c - can you determine the Extended UD table? If so, run a SQL Query against it to see if you have data corruption - you are looking for Boolean, Text, or Numeric columns that are “Null”.
I’m afraid I have combined two completely different issues into this one thread. Sorry about that.
Issue 1. Every time MRP runs, we get thousands of informational messages “Canceling from .Ctor” in the server log (but none in MRP logs). I have found no other information in server logs or MRP logs. I have narrowed down the process that generates the messages to the MRP subtask Erp.Internal.MR.MrpExpSched. And from the time stamps in the MRP log the activity is “Scheduling new unfirm job”. When there are 8 new unfirm jobs created by MRP, there are 8 Cancelling from .ctor" messages. I can manually reschedule one of the unfirm jobs without issue or error.
Issue 2: (One time this error occurred simultaneously with the Issue 1 MRP error, but that was just a coincidence, and not repeatable). During Cash Receipt Entry, after entering a customer, check, amount, and allocating an invoice, and hit Save. I see errors shown above in the server log relating to UD fields being NULL and NULLs are not allowed. Error is reported in server log, not to user, and Cash Receipt Entry functions just fine. Within Cash Receipt Entry, if I make a change to a new Cash Receipt, and Save, the errors are not reported, so the issue is only on first save of the Cash Receipt. There is a change log BPM to log many fields in the InvcHead table, but not the UD fields that generate the error. And there is no change log BPM for CashHead at all. The server log includes a total of 41 individual errors, for PbsCompleted_c, Checkbox01 through Checkbox20 and Number01 through Number20, all with the same error “Value cannot be null”, and none of those UD fields were created or used by any customization that I can find. Someone told me that those fields exist in the standard 10.1.400.37 demo database as received from Epicor, but they are not in the 10.2.200 database that I have access to now.
Sorry for the long winded explanation, if anyone is still reading, let me know if you have any ideas on either issue.
Are there any custom MRP processes?
Are there any required UD fields on any job related tables?
There are no custom MRP processes.
There are no UD fields defined on Job tables, but there are some UD fields on Part, although none of them are checked off as required.
I do see a lot extra UD fields on InvcHead, OrderHead and CashHead that I did not create with names like Character01 and Number01. Not sure where and when they came from, but they weren’t there right after our migration from 9.05 to 10.1, but they are there now that we have upgraded to 10.2.200. None of them are checked as required.
Hi, has anyone got to the bottom of this in the end?
Nope. No resolution or explanation. I just checked the server log and found 1500 ‘Canceling from .ctor’ messages from the MRP run at 3:00 am this morning. Still no errors in the MRP logs.
For what it is worth, .ctor refers to class constructors in c#.
Are any BPM’s called during the MRP process? Perhaps one of them has some “bad” C# code in it.
I have no BPMs on any MRP related Method.
I do have Change Log Data BPMs on Part, Order, Quote, Job that may get triggered during MRP, but no errors are generated except during MRP.
I know this is an old thread but since it hasn’t been resolved. I wanted to add what I found since I also see both in my EventViewer.
-
This is yet another one of the Events that can be ignored. Epicor devs in 10.2.200+ seem to like to write to the event log a whole lot more. Perhaps for finding other issues but I’ve found many messages in the event viewer that where never there in the past and can just be ignored (unless you are having an issue with MRP - then they help to diagnose whatever your issue might be - hanging for example). It’s just saying that a constructor is being deleted, which is basically frees up memory after it’s done doing what it needs to do. In my case they were tasks to schedule unfirm jobs.
-
I believe this is a bug in Epicor where the Database regen didn’t include InvcHead_UD in every place it should have. So when cash receipt goes to write a record, it does not include any _c fields that may have been added and fails because the field is not a nullable boolean (?bool) but instead a boolean (bool). There’s no way to make this a nullable boolean through the UD Column Maintenance so to correct this, you will probably have to hire Epicor to write a patch and update the patch every time you add a field to InvcHead_UD and since it’s not breaking anything, another you can ignore - though it is irritating to see it. There was another bug in the Cash Receipt form related to the menu maintenance screen (for which there is a patch) which leads me to believe Cash Receipt was just neglected a bit during the recompiles.