Speak of the devil... ancient configurators resurrecting?

Kinetic ERP
,
1

I just mentioned a problem I once had (in another version, at another company, on prem instead of SaaS) where old versions of UI forms kept resurrecting out of nowhere. Now something eerily similar is happening to my configurators.

My Pilot environment was copied over Third this weekend, so I approved and tested my configurators on Third to make sure everything copied correctly. What happened next defies explanation.

The first thing I noticed was that an input that was supposed to be bound to a global wasn’t being initialized correctly. This was a bug I remembered fixing, so I initially assumed that I’d just forgotten to fix it on Pilot when I fixed it on Third. But I had fixed it on Pilot. Everything was bound correctly, at least according to the version I could see.

I unapproved and reapproved my top-level configurator hoping it would regenerate correctly, and something even stranger happened. It regenerated with an ancient version of my On Page Leave expression that just displays a dialog that says “On Page Leave.” This hasn’t existed for a long time, and never existed on Pilot. When I edit my On Page Leave expression, it shows the current version of my code that does not display that dialog. And yet, there it is on my screen.

It appears that Regenerate Configurators is compiling ancient versions of my configurators that I can no longer see or edit! And what version they regenerate changes from one minute to the next, every time you unapprove and reapprove. This is what we’re paying more than my salary for?

1 Like
2

I’d put money on what happened. Somewhere in Epicor there’s a LINQ statement that assumes an EF enumerable is intrinsically ordered and takes the First or Last result without an OrderBy. The DB gets restored from a backup or compacted or something, the rows get restored in a different physical order on the disk, and kaboom! I’ve seen a similar bug in a REST integration where someone assumed a newly added OrderDtl would be Last. Nope!

1 Like
3

I was going to say check

SELECT * FROM Ice.Customization WHERE Type = 'ProductConfigurator';
SELECT * FROM Ice.CustomizationStore WHERE Folder = 'PC';

But it may be LINQ Issue as you said, notice how the SQL is in odd order.
imageimage

4

I don’t know what this means, but some of the Target, Project, and Assembly columns in Ice.Customization mention VER1, VER3, or VER6. For example, one Target is MFGD_VER1__DomeSub. There are two rows for each of my configurators, with Targets formatted {company}_{version}__{configID} and {company}_{version}__{configID}A_.

Ice.CustomizationStore is not accessible to BAQs…

6

Support suggested regenerating the data model, which of course took a day. Things remained weird.

I have a dynamic list populated by a UD method. The call chain throws a NRE before reaching my code. PageLoad calls TriggerAllDynLists which calls a few other things. Eventually it calls a client-side proxy for my UD method, which calls client-side ExecuteUserDefined, which calls server-side ExecuteUserDefined. The server-side method throws a NRE. I tested this by changing the first line of my UD method to throw a different exception. It’s not hit.

So they’re going to try the backup and restore again, which will probably take another day. I’m coming up on an entire week lost for something that should take an hour.

7

They ended up repeating the backup/restore and everything just worked this time. They didn’t say what went wrong the first time, but I hope they at least know internally…

1 Like