Heresy!
Just my 0.02$, but if you get datafixes weekly, something is wrong⦠Your time would be better spent finding the cause of the corruption IMHOā¦
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.
This thread was pretty helpful in knowing that data fixes are common even though we have pretty limited custom setups, like adding a user char field and moving some fields around. Currently, I have two tickets open with data fixes sent over by Epicor for issues users are finding during training in Pilot before our golive. Each issue only affects one user, no one else.
Is that common as well, where the issue is only affecting one user? Are the fixes trusted implicitly, so you just run it without fully understanding the code? My manager is concerned about the ramifications of this code and what it is doing
The only user-specific issues Iāve seen were related to corrupted smart client caches. The weirdest one was a user who was getting errors that could have only come from the Pilot instance, which he didnāt even have access to, plus he was working in Prod. Clearing client cache fixed it.
I wouldnāt say those issues are common.
Trust implicitly? No. I run it on a non-production instance and see if it even did anything for the issue itās supposed to fix, never mind cause side effects.
Having said that, Iām not particularly worried about a fix making things worse.
I have to clear stuck tasks all the time. I generally just run DELETE FROM Ice.SysTask WHERE SysTaskNum IN (<list of sysTaskNums>)
and DELETE FROM Ice.SysTaskKill WHERE SysTaskNum IN (<same list>)
You can get some grief if thereās a systaskkill record for the same task.
Having said that, Iām not particularly worried about a fix making things worse.
We are 100% running it in our non-production instance first, but since we are before our go-live and training users, I think of it as our prod for now. Thank you for the reassurance. Our bigger fear was messing with something else we knew nothing about since we are still new to Epicor and learning it all. (Mostly me and being new to databases in general).
Also, this might be the fastest response Iāve gotten on a forum anywhere even if itās 3 months old, thanks!
Iāve had a few āuser-specificā issues in the past couple months (requiring data-fixes) and they were caused by corrupted personalizations. You can clear personalizations and reset things to default⦠but something behind the scenes in Kinetic remained corrupted.
For example we had one user using Shop Tracker. Everything worked except one grid wouldnāt populate⦠worked for everyone else. He had personalized that grid (moved columns around, etc.) and somehow it broke. But nothing we could do locally would fix it. They knew the issue and sent a datafix pretty quickly, so, that was nice⦠and hopefully since it was a known issue and fix itāll be patch to prevent in future releases.
NO!!! Never trust these things implicitly. We were burned terribly about 5 years ago with a bad FIFO layer fix⦠the āfixā blew up our FIFO layers and it took over a year to straighten out (we still see remnants here and there).
So now I demand to see the SQL behind every fix and they give it to me most of the time. Iāve caught a few more bad fixes that way (bad as in they wouldnāt solve the problem at hand, not necessarily blow up our system again)⦠the problem is there are so many front line support people that go straight to proposing data fixes before really trying to troubleshoot with youā¦
I never really looked into trying to decrypt the DFs myself, that would save a lot of time⦠@jgiese.wci do you have a way to do this?
You should be!
I do my due diligence. I simply havenāt seen it wreck anything. YMMV, clearly.
When you install at data fix it gets added as a stored procedure to your Db so you can look at the detail there.
Normally appears at the top of the list of the Programmability node⦠Donāt have any data fixes for the versions installed here so I canāt apply to confirm the name, but it should have something like TASK and a series of numbers at the end.
The stored procedure is rather convoluted, but I am sure it depends on how complex the data fix is, it does appear to have a lot of information about the data fix not just the data that is being repaired. I am sure that will also vary from fix to fix
I hope that helps.
Saas peeps sorryā¦
I believe we used a RedGate tool to do it.