1 of 1 people found this helpful
You say this may have a negative impact on other users of the query, in that case, you could always make a copy of the query so that you have one that refreshes automatically and the other which doesn't. Then it's just about setting up the correct views and dashboards so each set of people see the query you intended.
This can all depend on how the people you mentioned like to work; what do you currently have the refresh rate set at? As a compromise you could always set this a little higher, that way it's not refreshing so often that it's a pain to work with if you're on another page but frequent enough that you're not looking at a fairly out of date list.
This is probably too simplistic, but if they are always scrolling to the end they could use the >> arrows to get to the last page with one click. And/or give them a version of the query which sorts the other way round.
I know I said the bottom of the list but sometimes the incident they want to open is in the middle which would still require scrolling.
We currently have our queries set to refresh after 5 minutes but, for this particular one, it has been set to 10 minutes as a compromise for all users.
Just my 2 cents, for what it's worth.
We actually turned off the refresh rate as suggested by support.
Queries with auto refresh rates, specifically work load lists, tend to take up memory on the server, even if you have the memory leak patch applied.
Especially for those analysts who log in and then leave there work load lists displayed all day long.
Of course this depends on how many analysts you have.
If your setting the refresh rate to 10 minutes, you might as well turn it off as it's just as simple to click on the refresh button.......
What's the memory leak patch that you refer to?
The patch is for Problem 4451 for release 7.3.X.
If you open a ticket with support, I'm sure they would be happy to send you the patch.
It involves applying a couple new DLLs.....