Ok, I know there have been multiple posts on Silent Parameters. As a matter of fact, I started one once.
And there is even a feature request.
Now, I do not even remember why I posted my original thread. But 2 years later and a lot more experience, I have realized that there is no need to have parameters on a BAQ. You can filter the query results by using the Tracker Panel and setting the correct options on the fields. This will send a Where clause on the Dynamic Query Execute method and only return the records you want.
Now, I literally just figured this out yesterday and have not thought everything through, but isn’t this exactly what we have all been looking to do?
Please let me know if there is another reason to use the BAQ Parameters that I missed or any other questions/comments. I am bringing this up as more of a discussion to see what other more knowledgeable members might say.
I would agree that it shouldn’t be necessary very often. From what I’ve seen the when the dashboard is run with filters in the tracker Epicor converts it to a CTE (It might just be a subquery) and applies the filter to it as a where clause in SQL. There are times when the SQL where clause can be very slow, but that can often be fixed by reworking the query. Things like a recursive BOM listing might have poor performance.
Are you limiting the question to dashboards? The title of the post does, so this may be a foolish question of mine.
But if you mean this generally, I am beginning to find them very useful in RDDs and REST calls.
I had been taught that they are kind of silly, just use the dashboard filters. But there is a bigger world out there…
I also have tinkered with the idea of making some big queries as reports with the intent that they would always be printed/submitted as CSV. That way it could run in the background without tying up the client. (As opposed to a dashboard.)
I was just limiting it to Dashboards, but you bring up a very valid point, especially with REST. If you put a parameter on a BAQ, then you need to enter something before it will run (if you made it mandatory). This would ensure that someone does not submit a REST call wide open.