Managing Schedules

Schedules are used within SSRS to trigger executions of subscriptions and snapshots, generally classified as events. Schedules can trigger a one-time event, or cause events to run continuously at specified intervalsmonthly, daily, or hourly.

Schedules create events on the Report Server. Actions within the Report Server, such as expiring a snapshot or processing a subscription, are triggered by the event. What SSRS actually does is create a scheduled job on the database server that hosts the SSRS database. The SQL Agent then runs the jobs, which usually contain nothing more than the command to execute a stored procedure to trigger an event. The other half of the Scheduling and Delivery Processor within SSRS is the Report Server Windows service referred to as SQL Server Reporting Services under services in Control Panel.

This service is responsible for querying the database server for events and running the processes that those events trigger. Both sides of the Scheduling and Delivery Processor must be enabled for it to work. If the SQL Agent on the database server is turned off, the jobs do not run, hence the events do not fire and the corresponding actions are not taken. If the Report Server service is down, the jobs show that they ran successfully, but no processing actually occurs.

Types of Schedules

There are two types of schedules used in SSRS: a shared schedule and a report-specific schedule. The relationship is analogous to the relationship between a shared data source and a custom data source. The shared schedule can be used to trigger a number of events throughout the Report Server. A report-specific schedule is used for one and only one specific event. A second event might occur at exactly the same time, but as far as SSRS is concerned , it is a different schedule. Because they are so similar the question often brought up is, "When should you use a report-specific schedule over a shared schedule?" In general, create a report-specific schedule if a shared schedule does not provide the frequency or recurrence pattern that you need.

Table 20.1 details the difference between shared schedules and report-specific schedules.

Table 20.1. Shared Versus Report-Specific Schedules

	Shared Schedule	Report-Specific Schedule
Permissions needed to create/modify	Needs system-level	Can be created by individual users
Can be temporarily disabled?	Can temporarily pause and then resume shared schedules	Have to be modified to change the time
Manageability	Are managed centrally from the Site Settings tab in the Report Manager or Object Browser	Have to be managed from the individual items
Customizable	Cannot be customized for a specific item	Can be easily without any other downstream implications

Creating/Modifying Schedules

The process for creating or modifying schedules is generally the same whether it is a shared or report-specific schedule. The only difference is the scope. For the shared schedule, it is created once and can be referenced in a subscription or property page when you need to specify schedule information.

From Report Manager or Object Explorer, administrators can specify which items use the shared schedule. Report-specific schedules are created and referenced by only that one report, subscription, or report execution operation to determine cache expiration or snapshot updates.

To create a shared schedule using SQL Server Management Studio, follow these steps:

1.	From Object Explorer, navigate to the Shared Schedules folder, right-click on Shared Schedules, and select New Schedule.
2.	Enter a name for the schedule.
3.	3. Select how often you want the schedule to recur or select Once for a one-time event.
4.	Click OK.

Alternatively, you can create a shared schedule from Report Manager by completing the following steps (see Figure 20.1):

1.	Navigate to Site Settings.
2.	Click Manage Shared Schedules under the Other section toward the bottom of the screen.
3.	Click New Schedule.
4.	Enter a name and how often the schedule should recur, and then click OK.

Figure 20.1. Creating a new shared schedule in SSRS.

After being created, a schedule can be modified at any time. Modifying the schedule of a running process (subscription, snapshot, and so on) does not cause that process to stop. If the process that a schedule triggered is already running, modifying the schedule serves only to start the process again at the new time.

Deleting a schedule does not guarantee that the events that it triggers will stop firing. Deleting a shared schedule only serves to create report-specific schedules for any items that reference it. A better way to stop a schedule is to expire it, by putting an end date on it. Expired schedules are indicated as such by the status field. Schedules that have been expired can be restarted by extending the end date.

Another alternative is to pause a shared schedule. A paused schedule can be resumed at a later date and time. Report-specific schedules cannot be paused . Pausing a schedule is similar to modifying it. Pausing the schedule of a process that is already running or of one that is in queue only stops the subsequent runs. It has no effect on the currently executing process.

Note

Administrators can pause schedules from Report Manager.

To pause a shared schedule, select it from the list of the Report Manager schedules, and click the Pause button. The same process is used to delete a shared schedule.