Upgraded to Kinetic, our stock status report that took 45 minutes in E10.
It is taking 3 hours. The spec on the VM has even double the CPU power and RAM in the Kinetic.
Is there anyone who has similar issue can help me to find out which setting I can change to make the report to come out faster?
Update SQL server statistics.
If stats and defragging the indexes make no difference, Run the report with SQL profiler then run the results through the index tuning wizard and review the recommendation.
We’re on the SaaS cloud, and we’ve encountered the issue after multiple upgrades over the past two years. I had to get Epicor Technical support involved each time… create a support ticket explaining to them that the stock status report is running extremely slow following your upgrade. There’s a special fix they have for customers who encounter this issue.
One upgrade (I believe it was Kinetic 2021.2) actually broke the Stock Status report for us completely. I spent 3 days working directly with one of Epicor’s VP’s, Technical Support, and Developers figuring it out and trying multiple things until they finally got it resolved.
So, hopefully by this point, it won’t take you too much time to get if fixed. You should just need to make them aware of it, as you aren’t the guinea pig like we were.
1 Like
That’s interesting. We also just upgraded to Kinetic (moved to brand new servers) and I’m seeing Stock Status take longer than it did in 10.2.700. We’re still investigating / performance tuning, but I’m wondering if Stock Status itself is just slower in Kinetic now. No other performance issues for us so far.
After the upgrade to 2022.2.11, we find that computers with 8GB will be a lot slower than computers with 16GB. The client took 20 seconds to launch in Kinetic while E10 took around 11 seconds. I will make some incremental change each weekend and see if I can improve the system. I have schedule weekly reindexing task in the SQL, update statistics every 2nd day. I will update and see what is the most effective way to increase the performance of the system.
Hi Timothy, what does the “fix” do?
I really couldn’t tell you, as they’ve never detailed it. I just know, from working with the VP of Epicor Support almost two years back, that it was something they were having to do with all of their cloud customers following a specific release.
-Historical FYI when it became an issue for us: Our primary issue, at that time, was having a UD_table (forget which parent table it went to, but for SaaS cloud customers, they kept all of the Character01, Number01, Date01, etcetera fields when they upgraded from E9 to E10 - converting them all over to UD fields since adding & removing UD fields requires a bit more coordination when working through the SaaS cloud support team - thus they just made all of those fields available for use, whether they were being used or not).
Then, they “improved” the stock status report, and everyone who had UD fields against one of the table encountered extreme slowness and/or errors.
My first suggestion, since we were not using any of those UD fields, was to remove them from the database altogether - which should have worked. But it didn’t, and after three days of trying to figure it out, Support, Technical Support, and the Developers couldn’t figure out why removing the UD fields & table didn’t work. And since their fix involved having those fields, I had to add one UD-Field back into epicor, so that they could apply their fix.
Long Story short, they “improved” the report, which then didn’t play well… and even after our last upgrade to Kinetic 2023.1.5, our Saltillo Plant had to open up a support ticket for the Stock Status report again. It just seems to be a recurring thing during each and every upgrade. Thus, I have absolutely no idea as to what their exact issue is and how they go about fixing it. It’s all done on their end, since we’re a Saas Cloud environment. (It’s definitely not through the Data Fix Workbench, as those types of fixes I apply on our end).
1 Like
Thank you for the details! It’s clear that Stock Status has been plagued with issues for years…
I did finally figure out my particular performance problem, and I have to thank @HLalumiere for his advice:
Turns out we had a bad case of Parameter Sniffing going on. What is Parameter Sniffing in SQL Server? (brentozar.com)
We run the report 4 times per night for each of our 4 Sites. The PartTran data in Site 1 is orders of magnitude smaller than Sites 2 and 3, but SQL Server seemed to have cached an execution plan with Site 1 as the parameter.
I ran a job to update SQL Server stats ( SQL Server Index and Statistics Maintenance (hallengren.com)), then ran the report for Site 2 and it finally completed quickly (Site 2 had been timing out for weeks)!
I already have an update stats SQL job running once a week on Sundays, but I figure the change I need to make is scheduling Site 1 Stock Status to run after Site 2 Stock Status - that way when the execution plan gets cached it will be optimized for Site 2 (our largest site). 
I think I just ran into this. Stock Status was running great for months and then we added a UD field to PartPlant. Now it’s slow again 
Open a ticket with Epicor support and tell them that the Stock Status reports is running excessively slow (or if it is erroring outright, then send them the detail from the error message).
I have had a support ticket for what appears to be the same issue for the past month. I have uploaded my database to them twice now and they are claiming my company that’s been on Epicor since 2002 doesn’t have any parts in the part table 
so no resolution yet.
We are still on 10.2.500, but I have tested this on every major Kinetic release and all have this problem with stock status. I do have UD fields on PartPlant as well, but I have tried removing all of my UD fields, regenerating the DB, and the report still takes a significant amount of time compared to E10.