Reporting parameter saving

Question

In SSRS, User wants his report parameters selection should be remembered.That is for the first time user will select parameters and somehow next time onward it should rememb

Answer 1

The My Reports feature allows users to build and save their own reports on the server. It also allows them to create linked reports that have parameter defaults set up the way they want. That's the only built-in feature that might get you what you want. It is pretty limited, though, to be honest.

On the other hand, you could build a user parameter storage feature of your own. Here's a rudimentary example.

Start with a table to store your user report parameter values.

create table UserReportParameters (
    UserName nvarchar(50),
    ParameterSet nvarchar(50),
    ParameterName nvarchar(50),
    ParameterValue nvarchar(max)
)

Since you're seeking a way to store a user's parameter values, I'll assume you're using some sort of authentication on your reporting service, such as Windows Authentication. We'll be storing the UserName provided by that authentication service along with an arbitrarily named ParameterSet. This ParameterSet value could be the url to the report or some other unique identifier for the report or perhaps a logical name for a set of reports that all use common parameters such as "Sales Reports".

We'll need a way to save these parameter values. A simple stored procedure will do the trick.

create proc SaveUserReportParameter (
    @UserName nvarchar(50),
    @ParameterSet nvarchar(50),
    @ParameterName nvarchar(50),
    @ParameterValue nvarchar(max)
)
as
    delete UserReportParameters where UserName = @UserName and ParameterSet = @ParameterSet and ParameterName = @ParameterName
    insert UserReportParameters select @UserName, @ParameterSet, @ParameterName, @ParameterValue

Now in your report's main dataset query or stored procedure (somewhere you can be sure the code runs once per report execution) you just need to call that stored procedure to store each value.

exec SaveUserReportParameter @UserName, 'Sales Reports', 'StartDate', @StartDate
exec SaveUserReportParameter @UserName, 'Sales Reports', 'EndDate', @EndDate
exec SaveUserReportParameter @UserName, 'Sales Reports', 'DepartmentId', @DepartmentId
exec SaveUserReportParameter @UserName, 'Sales Reports', 'PromoCode', @PromoCode

Note that the table stores everything as nvarchar. I'm being lazy here and letting implicit conversion happen. If you want to store values such as datetime in a specific format, you'll need to convert them when inserting them into the table variable. The @UserName report parameter used here and below should be an internal parameter whose default value is =User!UserId.

Now that we're storing parameters, let's start using them. We'll need another stored procedure. This one's a bit bigger.

create proc GetUserReportParameters (
    @UserName nvarchar(50),
    @ParameterSet nvarchar(50),
    @Columns nvarchar(max)
) as

    declare @sql nvarchar(max)

    set @sql = '
    select * from
    (
        select
            p.ParameterName,
            p.ParameterValue
        from
            (select @UserName UserName, @ParameterSet ParameterSet) stub
            left join UserReportParameters p on p.UserName = stub.UserName and p.ParameterSet = stub.ParameterSet
    ) v
    pivot (
        min(ParameterValue)
        for ParameterName in (' + @Columns + ')
    ) as pvt'

    exec sp_executesql @sql, N'@UserName nvarchar(50), @ParameterSet nvarchar(50)', @UserName, @ParameterSet

And then to call it

exec GetUserReportParameters @UserName, 'Sales Reports', 'StartDate,EndDate,DepartmentId,PromoCode'

As you can see, you provide the UserName and ParameterSet values. The same as you used when you called the save procedure. Here, though, you're also providing a string that's a simple comma separated list of column names. These column names are used by a pivot query to ensure your result set includes columns by those names. You should be aware those columns can and will contain nulls, especially when a user first accesses the report. You should also be aware that all values are nvarchar(max). If you need to parse or convert any values or provide your own defaults when the value is null, you'll need to do some extra work.

In an embedded dataset named UserReportParameters I call the procedure, store the values locally and then do my conversions and null-swapping as necessary.

declare @Parameters table (
    StartDate datetime,
    EndDate datetime,
    DepartmentId int,
    PromoCode nvarchar(50)
)

insert @Parameters
exec GetUserReportParameters @UserName, 'Sales Reports', 'StartDate,EndDate,DepartmentId,PromoCode'

select 
    isnull(cast(StartDate as datetime), dateadd(day,datediff(day,0,getdate()),0)) StartDate,
    isnull(cast(EndDate as datetime), dateadd(day,datediff(day,0,getdate()),0)) EndDate,
    isnull(cast(DepartmentId as int),15) DepartmentId,
    isnull(PromoCode,'FAKESALE') PromoCode
from @Parameters

Now, every time you run the report (more specifically, every time the dataset that contains your call to the save procedure is executed) the parameters you opt to save will be saved. When you leave and come back to the report page, the parameters will be populated with the last values you chose. Note that you don't have to save every parameter value. Just the ones you want to save per-user. You also don't have to use every parameter value that's saved in a given ParameterSet. If you have two sales reports, one that uses PromoCode and one that uses ProductCategory you can save both their parameter values in the 'Sales Reports' parameter set without worry that they'll interfere with one another. Additionally, you could easily create two separate datasets in your report, each pulling a different parameter set. For instance, if PromoCode actually gets saved in the 'Marketing' parameter set and DepartmentId is from the Products parameter set. Once you have this framework, you have a lot of flexibility in how your user parameter defaults get saved.

It is generally considered bad practice to allow reports to alter data. I agree with this conventional wisdom when it comes to domain data. However, this parameter-saving feature is really more of an extension of SSRS functionality, akin to report execution logging. I do not believe it violates the principle.

SCALABILITY -- This will work great for a small number of reports for a relatively small number of users. There could easily be performance issues in larger enterprise environments. (That's why I called this a "rudimentary example" at the start.) You could address this by redesigning the value storage mechanism. For instance, use pre-defined tables for each parameter set instead of dumping them all into a single table so you can avoid pivoting. I'll leave that decision and work to you.

Answer 2

Try this one. It's a bit long, I will just attach the document link here. Report Parameter Saving Solution