Still the most requested feature since the inception of ICE Tools 
10.2.600 is already at the door, no sign of feature. 
3 Likes
Yeah @Edge!! this is our most Voted for request!!!
Next time you are looking at Dashboards don’t forget this little guy!!! Pretty please with a cherry on top
2 Likes
EVA Cool, Functions Amazing, CDC Woah, API v2 Hell Yea!.. But what about BAQ Silent Params, actually something we are all hoping for every release 
Its definitely something we will use, abuse and push to the limit.
Indeed, this would be a game changer in dashboard development.
Right now I have a Dashboard and the user would like to search by Period Range… Pretty simple on the Details… But in the SUM() (Head) version… I have to make 52 calculated columns (52 periods) per1, per2, per3… then when they change the filters use C# to hide/show the period range Grid columns among many things… So 1 option is of course to prompt them for params however when you PubSub with Params and Refresh it gets quite annoying being re-prompted over and over and over again.
4 Likes
Ok I hear you all - we will break down and look at options.
11 Likes
Intentional or not, this was kind of punny…
1 Like
Okay, I’m here to relieve the pain caused by dashboard imperfection. I hope I will gain at least one unicorn
I see the requested feature as extending a query filter settings with ability to subscribe published columns from another query to parameters of current query. So, once user clicks a record in “head” query then child query executes with parameters values based on columns from “head” query. No parameters prompt form appears for child query in this case.
User be prompted for child query parameters if these parameter subcribing settings are not specified.
Another, but related question is whether you actually needed in ability to control how to rerun a child query when current “head” row switches. For performance reasons, child query filtering happens on client side.
As I understand, sometimes you want to re-execute the child query parameterized with current “head” row values and filter criteria. You should understand that this may cause a “DDoS” attack to server if user decide to navigate through “head” rows in dashboard quickly.
2 Likes
Well I think we are talking about Parameters (Actual Parameter Prompts) being able to put those parameters in a Dashboard Tracker, what you explained above would be cool too.
However I think the original intent of the quest was just to allow those parameters to be bound to controls in a Dashboard Tracker.
Right now if you put a parameter prompt in a query in BAQ Designer, and you then bring that query into a dashboard then you refresh the dashboard you are prompted (with a popup) for the query parameters. We want to be able to set or pass those parameters in from the query tracker itself, or even default those in or pull them in from a published (header query as you mentioned)
3 Likes
Right now I have to pull in 10,000,000 “Child Rows” in case they do click on 500 rows. But Id rather re-execute the Child and be able to do SUM(), AVG(), MAX(), Grouping over and over again for less rows on-demand as needed. I think I can accomplish that If I can Publish Columns from the Head into the Childs “BAQ Param Prompt” silently. then I can go wild with SQL Aggregates, grouping etc.
Makes it so much easier being able to do
InvcDtlInvoiceNum = @InvoiceNum ... bunch of SubQueries, PIVOTs etc...
And get accurate results with aggregate functions…
Being able to select (normal pub/sub) or (silent param pub/sub) or hybrid of both would be great and of course just like anything at your own risk and yes it could bottleneck SQL if someone doesnt understand how to build it properly.
I am sure you can architect this much better than we are explaining it. If you make it happen, we will do a GoFundMe Page and buy you a real unicorn!
Technically you are almost there… BAQ Prompts work, we just want to publish a column into them and the user never sees the prompt (silent, secret) in addition to re-executing the BAQ with new inputs when Publishers row changes.
1 Like
Could we consider adding a functionnality to dynamically ADD parameters against the query (Top and subqueries) from the dashboard?
It would be especially especially nice for those filtering situations where you have a complex queries with subqueries that you can’t get the performance out of by only filtering the top level from pubsub
1 Like
Dare I say CTE!!! Would love love love to use this with a nice CTE
2 Likes
Bingo! Recursive Job to Job, Serial Numbers, BOMs etc… It would make it so much easier to just run the Query with params and get exactly it than trying to grab it all and then filter on hierarchy and putting in customizations to look for ‘*\Job*’ etc…
2 Likes
yeah words
OMG, three CTEs within the single query. You are realy in love with CTE
2 Likes
Sometimes you need all the data’s
1 Like
All right so @Dmitry_Kashulin is claiming his future chances at finally acquiring a unicorn are at risk. I for one would never, ever deny anyone their shot at 
glory!
What if we scope it to just this for now:
When you add a Query (BAQ) to a dashboard your tab are: General, Publish, Filter
We are talking about adding an addition tab Parameters
it would look very much like the filter tab - except you cannot add or set columns here you simply see the list of BAQ parameters and you cannot control condition it is just equals.
You can then map that parameter to the same value options you have when setting the filter. If you leave it unmapped you get the prompt to enter the value like you do today.
If we go to size this and do, I want to keep the first pass simple. Every additional complexity layer adds significantly more cost and my goal is to keep this small enough that we might be able to just sneak it in one dark sprint. If it gets too big it goes into the ‘whose demands for the release get done’ scrum and past experience doesn’t bode well.
So if this basic set meets your needs, I’ll go grab a developer and get them to size it up for me.
1 Like
This needs to be in the add a tracker though. Not in the add BAQ. The tracker needs a field for the user to type in something that will be used as a parameter. So really just adding the parameters from the BAQ into the list on the general tab, would be all that needs to be done.
The way you proposed, the parameter may not be a column value, so the mapping as you explain it would be odd, because only columns in the query show up in the tracker.
3 Likes
Perhaps in that the instance of a BAQ having params it forces a tracker panel even and that does what Patrick described functionally but from the panel. The panel would be editable like normal but the query fields handled like native fields in any screen we can’t touch them. Not sure if that falls into the realm of not flying under the radar though lol
Got it I think there are two underlying concerns. The one that I was drawn in for is this problem:
When filtering results in subquery I do not want to pull back all data and do a client filter, I want to be able to use the published value from Query 1 mapped to a parameter in Query 2 so the result set to hte client is vastly reduced.
Your bringing up a related problem which is I want to add a query parameter as a user enter able criteria option. I will have to go back and look I haven’t spent much time in dashboards recently but I thought how it handled the criteria panels was to build a where clause and pass that up to the Dynamicquery service to run it already. My memory may be incorrect on that.
Ahh, I wasn’t even thinking of the pub-sub part of it. Yes that would be helpful for sure. I was just thinking of the simple single query dashboard. I figured that would be an easier nut to crack first.