Hello,
I get datafixes from support to fix issues that I think I should be able to fix myself, if I knew what tables/fields they were changing and how.
I was wondering if there is a relatively simple way to read what a datafix does to see if I can recreate myslef, if ever needed?
Even if I can’t recreate, I still like to know what they did, so I can request it specifically, if I run into the same issue again.
Any ideas?
My suggestion: don’t. It’s not supported and potentially damaging to the integrity of the system. You have to know exactly what you’re doing, and even then, there’s all the caching going on above the DB level that probably doesn’t like direct updates.
As an aside, I have, in the past, received SQL scripts as fixes for issues. I just ran them in SSMS, as they weren’t packaged in a DF. I could see exactly what they’re doing. They’re insane. I use them as reference whenever I have downtime and I want to buff my SQL skills by going down a DBA rabbit hole.
It’s mainly for my own information.
I like to know how something is fixed so I can be better at requesting a fix later, since I know what they did the last time.
If there is no good way to look, I won’t bother. Not a big deal…
I am also just a curious person! 
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.
in the ones I have gotten the text file they send has a description of the tables and generally what they are looking for.
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
UPDATE InvcHead SET InvoiceBal = 400.25
sort of stuff LOL
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.
Below id the current one I had them send me.
CR34443MPS_2023_2_5_SQL.zip (334.7 KB)
Likely all it effectively does is this
DELETE Ice.SysTask WHERE TaskStatus = 'Active'
@Banderson also has posted this BAQ in the past for this purpose. However may need some TLC for current versions
Like people have said it’s not something that was intended to be done, but that doesn’t mean you can’t do it if you wanted to.
You know, being Frideas and all, how about an Epicor Idea that fixes the problem instead of users running patches?
EDIT:
Allow removal of dead tasks from the System Monitor without Epicor Support: KIN-I-4767
Every day I come in and run that for 10.2.500. And it still happens in Kinetic for the other company.
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.
I think they can figure it out, I believe in them. They need to try harder and finish it. We all are supporting them and would love to see this end.
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? 
they just moved the patch to a process and called it a “Feature”
