SSRS Url Access and Paging

Question

I have an app that executes and displays reports from SSRS retrieved through URL Access (http://msdn.microsoft.com/en-us/library/ms153586.aspx) Unfortunately, one of these reports is HUGE, resulting in a lot of generated HTML, causing the WebClient to timeout during the call, or the browser to choke on the amount of HTML coming back.

Is there a way to specify what page of data I want to view, as well as know how many pages there are in the result?

Thanks

EDIT

Did a little more searching, and found that there is a rc:Section parameter that can be passed on the URL. It returns that page number. The problem now is, how do I know how many pages there are?

http://stackoverflow.com/questions/2540177/jump-to-specific-page-in-reporting-services

Answer 1

It depends on how you are specifically displaying the report. Are you building the report URL dynamically and then serving up the page? If so, you can add a couple of hidden parameters for paging and which page of the report you wish to display and customize the resulting URL. It's a bit of work on your part because you'll need to do some manual work but it will give you total control over the end result.

Update

SSRS has an expression for determining the total number of pages in a report:

=Globals!TotalPages

Unfortunately, this can only be used in the header/footer of a report however it is only available after the report has been rendered. You can see a good exploration of this global variable here. The article is for SSRS2005 but it still applies to 2008/R2. If you only need to display the page number in the header/footer then this should work for you.

Answer 2

The number of pages in your result depends on the InteractiveSize/PageSize of the report. This won't affect how much data is returned, though. The only way I can see,off the top of my head, is passing a parameter to the query identifying which pages from the result set you want returned. The user might need to select the pages to view from a parameter list.

Answer 3

While I kinda agree with paginating through the entity body by using query parameters, I am not so sure that you need to do this. 20mb worth of data is not a lot, and WebClient should be able to handle this without any problems.

Can you show the code where you are downloading the data? Maybe you are doing something that is inefficient and can be fixed easily.

If that doesnt work, then I would like you to create a system.net tracelog for your application that shows the timeout. From that log, we can see if the timeout is due to the read timeout on the socket, or some other reason. That will then determine future course of action.