Scheduling and Securing Deployed Reports and Data Sources in C#.NET

Making Code 128 Code Set C in C#.NET Scheduling and Securing Deployed Reports and Data Sources

becoming too large and from storing data that is too outdated to be useful to end users. After a report has snapshots available, you will see the snapshots on the History tab of the report viewer (instead of on the History page that is shown in Figure 12-14).

The number of report snapshots stored can be controlled. The Select The Number Of Snapshots To Keep option in Figure 12-14 shows that you can either keep an unlimited number of snapshots or define a limited number. The default can be set in the SSRS server properties. When you run a report, you have to select which snapshot to use, and data from different snapshots cannot be compared. So if you anticipate that your end users might need five years of historical data, or they might want to compare older snapshots with newer ones, for example, you should create a data warehouse and an online analytical processing (OLAP) solution that will allow users to look at archived data. One difference between the cache and snapshots is that the intermediate format of a report snapshot is stored in the ReportServer database rather than in the temporary database. Also, in contrast to cached copies, snapshots do not allow any change in the query parameters used to render the report.

The report history options are available in the Properties area of a deployed report. you will see a History link in the left pane of the report window. Three behaviors can be associated with report history, depending on which mechanisms you want to use to add elements to the history, as follows:

You can select the Allow Report History To Be Created Manually check box. This option enables the New Snapshot button on the History page of the report. You can select the Store All Report Snapshot In History check box. This option is limited by the number of snapshots to keep in memory defined either at the History Report level or at the server level you find this server-wide setting in the Site Settings area. You can select the Use The Following Schedule To Add Snapshots To Report History check box. This option is useful for keeping track of certain forms of data at certain times, independent of decisions made by users to create new snapshots.

A couple of important advanced settings for reports and users include setting a query timeout and defining whether linked reports are allowed. Often you will need to limit the maximum execution time for a report. This will limit the impact of a runaway query. In addition, you might want to restrict the ability to create linked reports for a user.

Although there are techniques (such as caching and snapshots) that help control the performance of a report, performance at the server level can be affected by one poorly performing report. To avoid this scenario, you can define the maximum time spent rendering a report. You can configure this option either at the report level found on the Execution page on the Properties tab for the report or at the server level, on the Site Settings page.

Content Manager is one of the item-level roles available in Reporting Services 2008. This role has the capability to remove the item-level task Create Linked Reports from a given role in order to define the groups that can or cannot create linked reports. Also, in order for a user to define the location in which the linked report is going to be stored, the destination folder requires that the user has the Content Manager or the Publisher role. Linked reports abide by the same rules for execution that regular reports follow. For linked reports, you can create cache versions and snapshots, and the execution snapshots can be stored in the History section of the linked report.