I’ve received questions in the past about whether the report server supports per user snapshost – that is report snapshots customized with different parameter values for a given user. The answer I have always given is no – you get one snapshot per report and that snapshot always uses the default parameter values.
Well, it turns out that some inventive users have come up with a ‘work around’; it involves some coding on your part. But here’s the sketch:
Though RS supports only 1 *execution* snapshot per report, it supports N *history* snapshots per report. Also, you can cause a history snapshot to be created programmatically. So there we have it – “all” you need to do to create a set of history snapshots with different parameter values is automate a few steps:
1) Set the default parameter values for the report using the SetReportParameters SOAP API
2) Call the CreateReportHistorySnapshot SOAP API after step 1.
3) Repeat – as in lather, rinse, repeat ;-).
The reason we’ve found out about this workaournd is that there is one catch – history snapshots have a resolution of 1 second in reporting services. That means that if you try to create 2 history snapshots within the same second (time), the second (order) request is *ignored* – CreateReportHistorySnapshot returns the same history id for the second request as for the first request. You’ll need to add a delay in your code to compensate. Based on the comment below from b5lurker, a delay of 1.001 seconds works well in practice.
Finally, since History Snapshots are identified in RS only by their ID and the time they were created, you’ll need to be able for your end users to correlate the history snapshots with their parameters. You can do this in multiple ways – store the correlation in a database somewhere, flat file, etc. Of course you could do it all within RS by storing the information as custom properties on the report itself by using the SetProperties SOAP API.
You’ll also likely need to create some management/viewing UI for controlling how many of these ‘history’ snapshots are stored on the server due to size limitations. You’ll also want to have the UI allow end-users to view the right snapshot.
Finally, you should consider this a work around not a recommended solution – due to the idea represented here if you have a set of interactive users trying to browse the report live, while you’re generating your history snapshots, they might see wildly different default parameter values.
Kudos go out to and from the MSDN Reporting Services forum that brought this workaround to our attention via their debugging efforts. Here are their threads, respectively. You may want to ask them what else they did to make this solution really work in their environments.
Take care and good luck,