Background: In Job Entry for a large job, expanding the tree as shown below takes about 6-8 seconds. The specific step I mean is expanding ASM 1.
But sometimes instead of 8 seconds it will take 10-11 MINUTES. And never an amount of time in between. But after that, no more slowness in the screen, till you move to a different job. When this happens, it happens for all users.
I have a workaround to this. In SSMS, change the Max DOP for the database from anything to anything else. It instantly frees up the hanging screen and all users can operate normally again. Sometimes I donât see the problem again for weeks. Other times it happens two days in a row (like yesterday and today).
Do you mean that when one user does this, all users are frozen / slowed down or that all users who do this are slowed down and those not on this screen, Epicor operates normally?
Just Job Entry and Job Tracker are affected, for all users that might try to use those screens.
I donât know what âthisâ is, though. They donât do anything bad. Theyâre just looking at info. But itâs not like every time someone uses Job Entry this happens.
Sorry I meant âthisâ as in if one user expands the tree, does it slow down the whole system for all users or just the user who expands the tree. You answered my questions though by stating it slows down Job Entry and Job Tracker for all users, but other areas of Epicor work fine.
Show your users how to turn on trace logging, point the log at a volume with a lot of space, and forget about it until it happens again.
Iâve noticed a few places where the client spams CheckValidRevision dozens, sometimes even hundreds of times in a row with the same parameters. This causes the UI to freeze. One of the PRBs is PRB0238469, related to creating a configurator, but it happens in other areas as well.
Yeah, I have to assume that changing MaxDOP either kills all active processes against the db or wipes query execution cache, something like that⌠This does sound like some kind of lock.
So, we run the Ola Hallengren script for IndexOptimize weekly. My understanding is that it does the stats and rebuild, but do correct me if I am wrong.
I donât think so. I imagine that was one of the first things I checked when it first happened, but maybe I only looked at the app server.
Interesting. Unfortunately I could not pull up the PRB on EpicCare and even searching for CheckValidRevision did not return anything on EpicCare. I donât understand why these PRBs are private sometimes.
We went live on May 2nd using the Kinetic Interface on SaaS
(will start a separate topic on thatâŚ)
We had to go to the Classic view of the job because the Kinetic interface could not handle the multiple assemblies and large BOMs for the jobs.
Waiting for a fix before we go Kinetic.
Epicor has a problem tag - PRB0248350
PROBLEM DESCRIPTION:
Job Tracker in the Kinetic view expands the subassemblies details too slow.
EXPECTED BEHAVIOR:
Job Tracker in the Classic view expand almost immediately
You arenât missing any information - they havenât worked on it since telling me I could close the case, because the created a problem for it. That was March 23, 2022
Iâve only been able to see PRBâs that are linked to my cases, not others. Also, PRBâs wonât show up in âMy Problemsâ for us customers until development accepts them. The first stage where EpiCare support submits the PRB, but Dev hasnât accepted it yet (e.g. maybe itâll get rejected with the famous âWorking As Designed!â) will not be visible to us.
A couple months ago I suggested that search would be more useful if it used a full-text search rather than a word-indexed search. In other words, searching for âUOMâ should return results with âPartUOMâ, âUOMClassâ, etc, not just the word âUOMâ alone. Support came back with a KB article written that same day that explained how to search with a wildcard. I suspect that someone hastily implemented wildcards from scratch because how they worked made very little sense. Preceding the search term with an asterisk changed it into full text search. That is, â*UOMâ did what someone familiar with regex would expect â*UOM*â to do. âUOM*â did nothing.
That KB article has since been revised, and wildcards have become a little more useful, but theyâre still weird if youâre familiar with regular expressions or filename globs. Apparently the presence of a wildcard changes it from a word-based search to a full-text search, because âUOM*â matches âPartUOMâ and â*UOMâ matches âUOMCodeâ.
Edit: Oops, nevermind! The docs are a lie now. The % wildcard does not work at all. At least before, the KB article accurately documented something that was weird.
