A pretty common pattern that I see exporting of reports through URL Access using a simple hyperlink. The hyperlink usually looks something like this:
<a href=”http://localhost/reportserver/?/SalesData&rs:Command=Render&rs:Format=EXCEL”>Sales Data in Excel Format</a>
At first glance, it doesn’t appear that there is anything wrong with this. However, if you are working in an environment where the data is highly volatile and the user needs to click on the link multiple times and see up to date information then you could experience some problems. To understand why you encountering problems, you need to first understand that implicitly when you access a report through the Report Server, you are estabilishing a “session” with the server. Fundamentally a session is a binding between a user, the report, and the data in that report. We use session to ensure that when you navigate between pages and otherwise interact with the report that the data within the report remains consistent.
Ok, so what does this have to do with the URL above? Well, when a user clicks on that URL, we create a session for the user, and pass back a cookie their web browser which will identifier that session later on to the server so we can find the correct instance of the report with the data that was in it. If the user, within that same IE session, clicks on the report again, and assuming the session hasn’t timed out (10 minutes by default), we actually render the report out of the cached data that has been bound to that user session. I know — disaster, right? The user was expecting to see that billion dollar deal that they just closed and instead they are just reminded that they haven’t meant the numbers for October yet.
So what do we do about it? Well, there is actually an rs:* parameter which tells the server “Hey, I know that you already have a session created for this user, but forget about it for right now, and create a new one”, that parameter is rs:ClearSession=true. By providing the rs:ClearSession=true parameter along with the request to the report server, you are ensuring that the server constructs a new session for the user and runs the report from a clean state, ensuring (assuming you have the report configured to use live execution) that the user will see the most up to date information possible. The nice thing about the rs:ClearSession=true parameter is that if there is not already a session estabilished, it is a no-op.