I have a set of reports than currently run from a 'Select Report' form. Users select the report name and the start and/or end dates they want to view, and the query underlying the chosen report looks at the controls on the form to filter the report to the selected dates.
We now want to automatically run some of these reports every Monday morning, to send out via email. The start and end dates for the reports will be Date() and Date()+14. I know how to code to run the report and attach it to email, but I can't work out how to programmatically pass dates to the form's underlying query, instead of it looking to the form controls.
I've searched for the answer but can only find answers explaining how to do one or the other, but not if it's possible to do both using the same report.
I've tried to use parameters in the report's underlying query instead, but then I get prompt boxes for the date paramaters when I open the report from the form, even though dates have been selected on the form and are passed through to the report as expected.
I've also tried to pass the dates via openargs instead of looking directly to the form controls, but then I can't work out how to pass those openarg values into the query, only to controls on the report. That means the displayed start and end dates are correct, but the date filtering isn't applying to the report. From stepping through it, the report loads the data before the OnLoad code runs which sets the controls to the openargs values, so they are null at the point the data is filtered.
Any help is much appreciated, I'm a bit stumped on the best approach from here. Thanks.
I have reached a working solution for this, it may not be the most elegant but it allows me to use a single report in the two scenarios of opening automatically for a specific date range, or opening at the users request with user specified dates.
I have amended the reports so their default record source uses Date() and Date()+14 for the report date range.
When the report is opened by a user from the "Report Selection" form, "User" is passed through via OpenArgs. The OnOpen event of the form checks the value of OpenArgs and if it is set to "User", changes both the report's record source and the controls that display the report date range to use the dates entered by the user on the selection form.
#kostasK. thank you for all your input, you helped me get to this solution.
Related
These were the requirements given for an SSRS report:
A dropdown for quickly changing dates to preset ranges, such as
"YTD" or "Last 12 months"
The selected option in the dropdown should be stored in the database for each user, and retrieved when opening the report
The dates should be able to be edited directly despite what has been selected
The issue is that parameters don't cascade their default values without refreshing, requiring the report to be re-run to take effect and store the option, then to be refreshed to actually populate the "Default Values" for the date. This can be fixed by using "Available Values" instead, but means that the date fields will no longer be editable.
This may seem easy to some, but it stumped me for a bit. This is the solution that now works.
The parameters that need to be used are RangeOption, StartDate, EndDate, StartDateCustomInput, EndDateCustomInput
First, we need to create a table in the database to store the user's report preferences. SSRS has a built-in field for the user ID, so this can be passed to remember what the user's last "Range Option" was.
We follow this up by creating two stored procedures, one that gets the last run option for the user, and one that sets it. The SSRS username is the built-in user ID field.
The setting procedure should be put into a dataset, which will refresh and store the "Range Option" when the dropdown option is selected.
The dropdown parameter will use the getter procedure as its "Default Value". Under Advanced, make sure this is set to "Never Refresh".
To get the dates to update automatically without the need to re-run the report and refresh, we need to use "Available Values" instead. Plug in whatever expression you want to use, which references the dropdown parameter (#RangeOption) The catch is that this makes the date unable to be edited.
To make the date editable, a second date parameter needs to be created for our start and end dates. These dates will use "Default Values" that simply grab whatever is in the original start and end date parameters. Then, point all of our report items to the editable date fields (#StartDateCustomInput,#EndDateCustomInput).
Now, the dropdown alters the original date parameters, which then alter the editable date parameters, without running the report. The editable parameters can be altered first if the user wants, and the report will run with whatever is in these custom date parameters. The downside is that the original date parameters do not seem to cascade if they are hidden/internal, so you will likely need to have duplicate visible date parameters.
For some reason, the default values for the date parameters cascade in this way, but not the original approach.
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.
Is there a way to determine what filter settings a user has selected in order to translate them into SQL?
I have a form in continuous form view that a user can switch to data sheet view, set filters on any of the columns, then flip back to the continuous form view to see the results. I have a companion report with the same format as the continuous form and want to filter it by passing it the criteria in SQL.
I am thinking I can use the recordset clone property to identify the records based on key value, but wondered if there was a way to detect what the user actually filtered on?
Ideas?
That is fairly easy. The form's Filter-Property contains the filter expression. You should be able to use it directly in the where-condition of the report.
I am working with SSRS 2K5 and I have some questions that I haven't been able to answer via Google related to Report Builder. I have built my report and I am using a Model to generate the report. It is my understanding that Report Builder does not support parameters when the underlying datasource is a model so I have setup a filter that the user is prompted to fill in prior to the report being generated no problem. Here are my two problems:
The filter in question is a date field. If I set my filter to do a BETWEEN (date from to ) there is no option to prompt the user for the values prior to the report being ran. Is there some way to get around this?
If I was able to get the above desired date range effect by placing the date field in the filters area twice: once with a condition of 'Before' and the other with a condition of 'After'. The problem here is how the filters are displayed namely Date and Date 1. Ideally I'd like these to be displayed as Start Date and End Date, respectively. Is there any way to do this?
Please let me know if I need to clarify anything or more information is needed.
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