Bad Example - Setting the report to run in a few minutes is annoying and can go wrong

Instead, you can run some SQL commands on your reporting services to trigger the running and resending of this report.

1. Use SQL Server Management Studio and connect to the database engine of your reports server
2. Click the New Query button
3. Run this SQL query, which gives you a list of all the reports with schedules:

   SELECT
   sj.[name] AS [Job Name],
   c.[Name] AS [Report Name],
   c.[Path],
   su.Description,
   su.EventType,
   su.LastStatus,
   su.LastRunTime
   FROM msdb..sysjobs AS sj INNER JOIN ReportServer..ReportSchedule AS rs
   ON sj.[name] = CAST(rs.ScheduleID AS NVARCHAR(128)) INNER JOIN
   ReportServer..Subscriptions AS su
   ON rs.SubscriptionID = su.SubscriptionID INNER JOIN
   ReportServer..[Catalog] c
   ON su.Report_OID = c.ItemID

4. From the Results pane, determine the job name of the report you want to trigger. Right click on the job name and click copy
   
   

   Running the SQL query will give you a list of jobs with subscriptions
5. Click the New Query button again to open a blank query window
6. Run this SQL query, replacing YourJobNameHere with your Job Nameretrieved from the last step

   USE [msdb]
   EXEC sp_start_job @job_name = ‘YourJobNameHere’

7. When you execute the query, the Message window should say Job ‘YourJobNmae’ started successfully.
   

   Good Example - Using a SQL query to resend the report

If you don’t receive the report – then you know you didn’t fix the initial problem, but now at least, you have a fast way to resend the report each time you change a Reporting Services / SMTP setting.

The main points I was arguing that it is better to backup directly to a network share were:

1. Hard drive space on the SQL Servers is not unlimited – Why use more of it with backups when you could use a dedicated file server?
2. In a disaster situation – like a servers hard drive dying – having backups locally is useless
3. The 1 Gigabit network is fast enough to handle the traffic when the servers backup over the network

Further to that, the servers here at SSW are backed up using Microsoft System Center Data Protection Manager 2010 Beta. DPM synchronizes the data from our SQL server every 2 hours, this removes the need to do transaction log backups. This aligns with the companies Recovery Point Objective (RPO) – which describes the acceptable amount of data loss measured in time.

For these reasons, I choose to backup directly to a network location instead of locally as recommended.