Skip to Content

Persisting Crystal Reports .NET web applications – I

It is known that the web applications are stateless. To preserve the state of the applications, ASP.NET provides several state-management features which preserve the page & control between round trips. These features can also help us persist the Crystal Reports, with this blog I would like to share how Crystal Reports can be persisted & why it is required.

Let us start with Persistence, which is a mechanism to preserve state for each user irrespective of page reload and redirects.

Why it is required?

With every roundtrip or request to a server for a page a new instance of the Web page class is created, for the web application are stateless, due to which all the information retained by page is lost. This behavior is also exhibited by Crystal Reports which is evident from the creation on of new temp files with every roundtrip or postbacks.

Where it should be applied for Crystal Reports?

It can be applied to CrystalReportViewer control & the report that is bound to the CrystalReportViewer control.

How many features I can use for persisting Crystal Reports?

You have 4 options to choose from – ViewState, Session, Cache or ApplicationState. It again depends upon the use of the Crystal Reports. You should also consider whether it should be per-page basis or application-wide.

  • ViewState:

ViewState is client-based state management option which is used to preserve the page and control values between round trips by ASP.NET page framework. This behavior gives us a little idea that it can be used for persisting the control information.  Hidden field in the current web page acts as a storage location. It is retained permanently for the postbacks to a single page. The report display & CrystalReportViewer object model can be persisted with it. Whenever there is a page load it persist the state of all report display. The number of controls, their complexity and the amount of dynamic information can be directly attributed to the amount of space used by it. A good choice for storing the things within the bounds of a single page.

  • Session:

Session is a Server-based state Management option which stores and retrieves values for a user. It uses Server Memory as its storage. Its scope is not limited to a page but can be used throughout the application.

It is a best way of persisting the ReportClientDocument or the ReportDocument object model, if the report has been encapsulated within either of them.

I would recommend Session as it easy to implement and commonly used.  You should ensure that report has low shareability otherwise persistence would be at the cost of performance and may affect scalability of the application as a separate copy of session data will be created for each user if there are large numbers of users accessing the same data. If the report is user specific then Session is your best bet.

if (Session["Report"] == null)

   boReportDocument = new ReportDocument(); 
   Session.Add("Report", boReportDocument);


CrystalReportViewer.ReportSource = Session["Report"]; 

I am going to cover Cache and Application State in my next blog. Though there are many things I wanted to cover when it comes Session and ViewState, but not everything could be mentioned as it would have gone out of the scope of this blog. 

Additional Resources:


  1. Understanding ASP.NET ViewState
  2. ASP.NET State Management Overview
  3. Control.ViewState Property


  1. ASP.NET Session State Overview
  2. ASP.NET Session State


You must be Logged on to comment or reply to a post.
  • Your session code will only work if you are viewing one report in a session, if you try to view another report, the session variable is in use and so the session variable is not updated with the new report…. rubbish.

    • The example was specific to one report. If you have an example for multiple reports, I’d encourage you  to share that with the community – either as a comment here, or as a blog, or as a Jive Document. That would probably a much better approach than calling someone’s efforts “rubbish” (?).