I navigate between different dashboard pages via action links.
I have on top of all the pages a dashboard prompt which contains a division as a dimension to filter on. This division has different roles so I have 3 aliases for it. However I don't want the end consumer to bother with these different roles, that's why I pass through the value of the division via a presentation variable.
But sometimes the value doesn't appear in the prompt but the analysis beneath it filters on the correct value (so the passing through seems to work okay. And sometimes it does work correctly.
I can't seem to figure out the difference from when it works and when it doesn't. I have the scope of all my dashboardprompts on 'dashboard' and actions from 'navigate to bi content' is also on 'dashboard'.
I don't pass through the value of the dimension via the presentation variable but I am using the 'is prompted' option. So this looks like the value is indeed in my prompt but just doesn't show up.
Has anyone else have had this problem and can help me solve this?
Thanks!
Related
I'm trying to create an analysis based on errors, so I hope I have little to no value in this analysis but I need a column selector to switch between different measures which can have an error.
When I switch to a measure which doesn't contain any errors, I get a nice 'no results' message but also my column selector disappears. How do you keep this even when the analysis results in 'no results' or maybe another way to work around this.
Thanks!
a) "Back" in the browser :-)
b) "Clear My Customization" in a dashboard context
c) Instead of a column selector, you can move that logic to a dashboard prompt which switches out the measure in the analysis itself. Since the prompt isn't in-line with the analysis code but a stand-alone object it will stay unaffected by "No results".
You'd say '"Measure"."#{vMeasureSelection}{Count}" in the analysis column formula and then have the presentation variable value from a prompt passed in there.
I have the first parameter (client drop down) that passes an ID to the second parameter to be used in the 3rd and 4th parameter. During testing all the parameters are set to visible to verify what's being passed. As soon as I hide that second parameter the rest don't refresh. Again, visible, correct info flowing through, hidden, DOA. I have this set up exactly like this on at least a dozen other reports with no issue. I'm not real sure where this going wrong since I can see the correct value being passed while visible?
I was able to duplicate your issue. While I can't find a reference to support my supposition, I believe that hidden parameters (even those with a default value) are not evaluated until rendering, which would explain this behavior. Data sets that drive parameter values are run prior to the report being rendered.
As you're talking about having trouble with dependencies between the parameter values, I assume you're using queries to drive your available values for parameters three and four. If this is the case, then simply embed the logic that relates the value(s) of parameter 1 to the value(s) of parameter 3 into the query that drives parameter 3's available values. By cutting out Parameter 2 and incorporating it into the query logic for parameter 3, you will work around this issue.
If you're having trouble accomplishing this, reply in a comment and I'll see if I can help. As it stands, I don't know enough about what you're trying to do to help any more.
Seems like once you set the Testers field on a Test Case in MTM, it will not allow you to clear it. You are only allowed to change it to a different value. Has anyone found a way to clear this field?
It is important to not get the "Assigned" Tester field confused with the Assigned To field. They are distinct fields on a Test Case work item. One reason why someone might want the Tester field to be blank is if a team all pitches in to help with testing during an iteration and leaving the assigned tester blank allows the team to know that no one has "picked up" this test to execute. The team member could then assign the test to his or herself and execute it.
The template pulls the Assigned Tester Values from a list using the 'AllowedValues' tag. Instead, simply change this to 'SuggestedValues'. That will allow for empty values - easy as that.
If you'd rather not allow free entry, you can also add a default value such as 'None' and use that rather than blank.
Unless you've customized your work item type, this field should never be blank after being saved. It defaults to the person who created the bug in all Microsoft supported process templates, and a value is required by default.
That being said, why would you want to change it to blank?
If you really, really want to be able to blank it out (which I don't think is a good idea at all), you'll need to customize your template. See the below guidance:
http://msdn.microsoft.com/en-us/library/ms243849(v=vs.110).aspx
I made a report with about 30 different rectangles and textboxes that have different visibility expressions depending on the parameters. (It's a student invoice and many different messages have to appear depending on the semester) When I made all the expressions I coded in the parameters in all upper case. Now I have a problem when users enter lowercase letters, the SQL all works fine since it is not case sensitive, but the different rectangles and textboxes don't show. Is there a way in the report code to first capitalize all the parameters before running the SQL? Or do I actually have to go back to every visibility expression and add separate iif's for upper and lower case? (That seems incredibly silly to have to do). I can't change my parameters to numbers because I have been given strict requirements for input. Thanks.
I do not know if this is the most elegant solution, but you could accomplish this by following this procedure for every parameter on the Report Parameters page:
1)Re-name the parameter, leaving its prompt as that of the old parameter.
2)Add a new parameter with the same name as the old parameter.
3)Mark this new parameter as Hidden.
4)Make sure that the new parameter's available values are marked as non-queried(available values will never be actually used.)
5)Mark the Default Values as Non-queried, using the following syntax:
=ucase(Parameters!OldParameterName.Value)
Can't you just UCASE the params (do it in the xml view, it will be quicker and you might even be able to do a regex find/replace)
I'm new to SSRS, so I apologize if this question is too simple:
I have a report which accepts a parameter called "Amount". I want to constrain valid inputs to currency values >= 0, and pop open an error message if the user enters improper values.
I don't want to validate inputs in my stored procedure and throw exceptions, because SSRS displays a very generic "Query execution failed for 'someTable'" message to users who access the report from another machine, and my business does not want to turn on the "Enable Remote Errors" flag.
How do I add input validation to report parameters and notify users of bad input?
Yes, I've googled around, but haven't had much luck. Thanks in advance :)
Okay, how about this?
All you have in SSRS, really, is the SQL query and expressions in report fields.
Perhaps you could add a big, red text box at the top of the report for your error message, and give it an expression like '=IIf(Parameters!Amount.Value < 0, "Error: Invalid Amount", "")'.
Then go to your table's "Hidden" property and give it the expression "=Parameters!Amount.Value < 0"
You could also add into your query's where clause and add "AND #Amount >= 0" so you aren't fetching from the database when there's an error.
It's possible to make report parameters in SSRS that are based on a particular list or a lookup query but I don't think you can apply a regex or something like that.
Instead you might consider separating your report into two panels, one which displays your report and one which displays an error and then you create an assembly with a function in it that validates the parameters for the report before it is run. If the validate parameters function is successful you hide the error panel and show the report panel, if not you do the opposite.
I don't think there's a whole lot you can do in the reporting tool itself. It's pretty rudimentary.
However, you can provide an ASP.net web interface or a form that you can use to ask the users for the parameter values in any format .NET allows, and use the ReportViewer control to display the report. It sounds daunting, but it's actually pretty straight-forward, particularly if you already have a project you can build on.
Microsoft gives tutorials for using the ReportViewer controls.