I’ve poked at the ones I’ve received. They’re not an archive, not text, and don’t reveal anything useful in a hexdump. That’s only like 60 seconds of effort but that’s where the effort curve goes vertical if you don’t have some prior clues or intuition about what to try next.
I’m curious too! Sometimes the datafix requires a hardcoded list of ID’s, which is probably less interesting? When they’re dynamically finding what to fix, that’s when it would be extremely useful to know what they’re looking for and how, so I can monitor for future excursions in real time.
Most of them you can just open in SQL Studio and there will be a thousand lines of code with 4 that you actually need somewhere near the bottom. They go in as functions in the dbo schema encrypted but there are ways around that then they become very readable. TBH a good majority of them are as simple as
Related and ridiculous thing: A record of every run of a data fix is stored in Erp.Local001 and every record updated or removed by a fix is in Erp.Local100, which is some obscure table they use to back up records in case the DF makes it worse. Check yours. It might be in need of a purge.
The one I am interested in is where they can delete active tasks that are stuck in system monitor.
I have to re-request the datafix every couple of months because the update expires it…
If I could see if it is doable by me, I would just do it myself, lol.
I don’t have any energy to pick this one apart and honestly it’d be a waste of energy cause they already know it’s a bug and a problem. Nothing in the software should allow us to create transactions that throw on hand quantities out of whack. I don’t care how much we want to argue that point… it just shouldn’t happen.
Yeah I mean I’m being a bit of a sarcastic jerk, but even Epicor gave up on this one and literally gave us a fix it “feature” cause they couldn’t figure it out either.
Ha, ha, no. I was thinking something a little less user interactive.
I believe, could be wrong, the SysTask record has the Windows Process ID that it’s running under. Having the TaskAgent use the Process class in .NET to check the status of the process to see if it’s still running, and if not, clear the Task from the Task Agent and set an appropriate status.
And if you want to get real
Start tracking the min, max, and average times a process successfully runs and issue warnings when the min or max has happened.
Finally, if you HAVE to remove the process manually, why not allow it in the UI?
I mean, if you’re running vanilla Kinetic with no customizations I would argue there’s some inherent flaw in the code that would allow for a user to be able to cause such corruption on their own using base Kinetic. My $0.01.
they just moved the patch to a process and called it a “Feature”
