is there a way to make a hidden parameter visible in SSRS Subscription creation ?
Something like this
The Parameter IsSchedule will be hidden/internal(not visible to normal users) but should be visible when i create a schedule for the report.
Note: the reason i want this to be possible is for my SQL to know wether the data request it is getting is for a sql report schedule or for a person who is trying to view the report.
this way my SQL query will know if the End Date parameter data should/shouldn't be updated.
You should be able to see all Hidden parameters in the Create a Subscription wizard, which you can then assign a value to.
If the new parameter simply doesn't show up, you may need to delete and re-deploy the report:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/337c7ae9-f15a-4718-9fac-e5c1d6a73f30/boolean-default-parameter?forum=sqlreportingservices
Related
I have an SSRS (2016) report that accepts a date parameter. The user selects a date and the report runs and returns one page per customer. The report also has a data driven subscription which when triggered, emails the output relevant to the customer.
My current approach is to have a text box that only some users can see and clicking the text box triggers the subscription . I do this by :
Inserting the parameter selected by the user into a table when the user clicks "View Report" button and then use the following to trigger the subscription:
EXEC msdb.dbo.sp_start_job #job_name ='job name to be sent out'
The data set for the subscription/ report then uses the parameter inserted into the table to do it's thing. This all works fine.
The problem arises when more than one person runs the report.. the second persons trigger can potentially over write the first persons parameter insert resulting in the wrong set of data being sent out..
My questions is.. is there a better way to trigger data driven subscriptions where the report needs parameter values - but the parameter value cannot be predetermined?
If my approach is acceptable, how can I eliminate the overwriting of parameter values?
Better still, how can I determine the correct parameter and pass it to the subscription? e.g. session id / user id.. etc.,
Any ideas or alternate implementations are welcome..
I've run into the same issue before, where a default table value is overwritten during processing from another user. The way I resolved it was adding a column to the default table for the HOST_ID or HOST_NAME. It's a bit of a pain because then you have pass that parameter to the report as well.
SELECT HOST_ID(), HOST_NAME()
OR
In a report parameter you can use the following expression default value to get the current user.
=Right(User!UserID, Len(User!UserID)-instr(User!UserID, "\"))
Note: Your data-driven subscription will fail if you set this as a report variable. As a parameter, it will work.
I'm trying to find a way to pass a parameter from a report to a subreport without resorting to any SQL code or macros (my officemates are non-technical, but still have to use the Access database to run reports, occasionally making tweaks to them.)
I'm working in Microsoft Access 2013. I have a table that contains a list of investments as well as which state those investments are based in. I have a query that pulls data on Investments based on a user-entered State parameter. I then run two reports: one that simply lists the investments grouped on different categories, then a second report that summarizes the investment categories into a table. I've put the summary report at the top of the detailed report as a subreport, but I want to pass the State parameter through from the main report to the subreport so the user doesn't have to enter it twice. Is that possible without resorting to writing any SQL code or macros?
Thanks!
I think I understand what you're trying to do, but please add details if my answer doesn't make sense.
You can pass user entered information by referencing by
[DatabaseObjectType]![ObjectName]![FieldName].
If the user is entering the State value from a Form, you'd reference:
[Forms]![FormName]![State]
where FormName is the name of your form, and State is actually the name of the Form control containing the State value.
If the user is entering the State value in a prompt from a query, you'd reference:
[Queries]![Query1]![State]
where Query1 is the name of your initial query that gets the state info from the user, and 'State' is the name of that field.
You put these references in to your secondary query or report:
for example, in a second query, you can set the State field Criteria (in query design view) to be = [Queries]![Query1]![State]
so the second query will pull the State value from the first query
on a report, similar idea - you can set the Control Source of the State control (in Properties) to be = [Queries]![Query1]![State]
I would like my users to be able to create their own quick and easy reports from a cube on the fly, and that is most simply done using the "Table or Matrix Wizard" in Report Builder.
However they need to filter by date--and it wont work.
I have tried:
1) Creating a dataset with parameters imbedded. When you run the report, it asks for a parameter but there are no values in the drop down -- and an analysis of the "Parameter Properties" shows no available values. (Even though I chose values when creating the dataset)
2)Creating two datasets, one with all the data and one with only the date field. However the matrix wizard will not allow you to use 2 datasets.
Is there any simple way to add a filter to the report so that my users can just load a dataset/two and then use the Matrix wizard?
Thank you!
If the user running the report needs to define a date parameter, they need to create a date parameter with the same name as the parameter in the stored procedure that is called by the report. They should then set the Data Type to Date/Time, and make sure the parameter is visible.
When the user runs the report, they will be able to use the calendar feature to pass the date value to the report procedure.
All,
I've been working on a custom timesheet report that uses multiple datasets (8 to be exact). Each dataset selects the data by the same ID field which is currently input as a parameter. It works great like that. But now I'm told that the end user wants to input a date and have all the reports printed out for that date rather than having to enter in an ID each time. Each timesheet is 2 - 3 pages. It is intended to emulate a form and contains some data but a lot of blank areas to allow the field people to write in any changes that have occurred.
My question, is this: what is the best way of accommodating the new requirement? Should I build it all as one big dataset and use the date as a parameter?
Should I create a wrapper report that would prompt for the date and then use the existing report as sub report? Would that even work?
Is there any way I can just create a new date parameter and put that ahead of the ID parameter and get them to print out like that? I've got a few hidden parameter fields on the body that get used in the page header and are used to link some of the datasets.
any help is appreciated.
Easiest way to achieve this is indeed by creating a wrapper report with the date parameter. The data set in this report will then fetch all items (with ID) that match the query by the user. The report can then have a list for that dataset, with the original report as a subreport. If you pass the ID parameter from the dataset to the subreport you wouldn't need to change hardly anything in the original report.
Two things to watch out for:
the Report Header and Footer in a subreport are not rendered - these are only rendered for the wrapper report
you may need to tweak your page breaks in the subreport and on the new list in the wrapper report so each new form starts on a fresh page
I suspect the answer is no, but here goes..
I'm using the WebForms Report Viewer on a public-facing website to allow users to report on themselves or their users (if the user is an admin user).
A report has a parameter called Users where an admin can pick a user from the list and generate a report from it. Mundane users can also view this report, but I programmatically create a linked report for each user and set the UserID value to their ID so they can only view themselves.
This works well except that the UserID parameter is query-based, and not every user is visible in the list using default settings (the user list is based off date range parameters can provide, and only users we consider 'active' during the date range are visible).
This is blowing up for mundane users that are not active for the default date range (which is the previous month).
I suspect the flow of execution is something like this:
Report loads with default parameters
The linked report rules are now applied and the value of the UserID is overridden with the ID in the linked report
UserID field is now hidden to prevent the user from changing it
SSRS can't find the UserID default value in the query results (that I didn't even want it to run) so it displays an error The 'UserID' parameter is missing a value
Through some testing I've found a perfect correlation between users not inside the default date range and users who can't view the report.
Can anyone suggest a way to make the report usable for those users that aren't in the default list? The reports are created programmatically so I do have a fair bit of control over the situation.
I would love to simply be able to mark a parameter in a linked report as no longer being query-based, but those properties are all read-only.
I really, really don't want to have to create duplicate reports to accommodate these users but I'm at a bit of a loss right now.
Any suggestions are greatly appreciated!
Go into parameter section of linked report.
Disable 'Has Default'
Click 'Apply'
Re-enable 'Has Default'
Click 'Apply'
and you're good to go!
I haven't figured out yet how to re-enable 'Query Based' as a default after removing it :(
Would be very much obliged had you found out......
Can't you just mark the param as 'nullable' then pass null in from the linked report ( you may have to alter the back end to cope with this?
Alternatively add an extra row to the 'users' day something like -1 "unknown user" then you can just watch for -1 and handle accordingly