Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
I want to hide the dynamic query parameters in a AX 2012 SSRS report dialog.
The report datasource is a query, which has a few predefined ranges. But in the report dialog, I just want to see the printer select box and not the query range fields with their predefined values. I set the status of the query ranges to hide, but ist had no effect on the dialog.
Is it possible to hide all the parameters at once for the report dialog?
If you use a report controler class, you can overwrite the showQuerySelectButton method and return false.
If you remove the ranges from the modeled query, and add them back programmatically in the methods of the query, they also will not show up as parameters for the report.
Dynamics AX/Sure Step - Online Support Engineer
When responding to posts, please 'Reply to Group' via your newsreader so that
others may learn and benefit from your issue.
This posting is provided 'AS IS' with no warranties, and confers no rights.
Thanks for the help.
I've tried both solutions und now I've just to choose, which one I use. :-)
You have to override the showQueryValues() of controller class and return false
What about the contract class parameters ? I tried to set the parameter's property to hidden in visual studio , it does not help.
Raj_kumar's answer is the most suited as you dont want to show query ranges and the button
contract parameters are can definately be hidden . Look at any report that uses srstmpTableMarshaller class (Pseudo tmp table report's ). or any document reports . Journal record id is generally passed from controller --> Design (via parameter value in contract class) -- >DP class.
But still its not visible on the report
All you need to is set its property to hidden in VS
I feel its more like issue with the usage data.
Once you set the property to hidden you need delete the report from report manager and then redeploy
remove usage data , delete records
in SYSLastValue , SRSReportQuery
restart Reporting services
@venkatesh vadlamani Thank you for your reply.
This morning when I try to run the report the parameter is hidden, i have not changed anything since yesterday I set the property to hidden, I think that it is the normally cache problem some I have had before.
anyway it works now, thanks again!
All are suggesting controller class but If the report is Query based report how can we achieve this? Without controller class can't we achieve this one through visual studio properties?
Allow dynamic filtering false and remove the dynamic parameter. redeploy the report and refresh the user cache.
This should do
Thank you Venkatesh, it is working fine.
you can set Datset properties > Dynamic filters = false in visual studio.
It seems that setting the "Dynamic Filters" option to False is not really the solution..
Doing so the query object cannot be accessed at all in X++ code.
The opposite doesn't seem to work either: If we set the "Dynamic Filters" option to True and try to make the query/query run non-interactive on the AX side doesn't seem to have any effect when running the report.
What we need a solution that:
- Makes the query options invisible to the user (Select button and query values)
- The query can be updated in X++ code (e.g. set a range)
I believe this is a typical scenario and there must be a sufficient way to achieve.. (e.g. print a report for a Vendor. The Vendor's account num must be set as a range)
Expecting your feedback.
How do you plan to use the query from x++ code when you have a query based report and you are reluctant to write a controller?
Making query invisible to user is already explained, create a controller and override the showQueryValues method in the initial reply, please browse the initial replies.
For other queries please use a different thread
That's the whole purpose of a query based report! That you don't need to create any classes, temporary tables or any other objects.
We are trying to minimize the work required for a simple report.
In the click method of the menu item button we just add a range to the report's query. As simple as that. I don't see where your surprise comes from.
The suggested approach to hide the query from the user simply makes the report non-usable. How often is it that you need to run a report that doesn't apply any filtering what so ever?
That's the whole purpose of a query based report! That you don't need to create any classes, temporary tables or any other objects..