Our reports in SSRS stopped sending. The last report was sent 2 days ago, and was send successfully, but since then none of the reports are being sent.
If I look at the SSRS web page for each report, there is no error. Simply showing the last run time as 2 days ago, so seems it didn't even try send.
Yesterday we did make some changes. But only moving a database from the Express version, to the regular version. We did not do anything that would affect the SSRS metadata (or at least we don't think we did...)
Where should we start looking to see why the report subscriptions stopped? Is there a process that could have accidentally been disabled? Thank you!
The Report subscriptions are created as jobs for the SQL Agent. You should see a long list of jobs with GUIDs as the names. Make sure that the SQL agent jobs are running. Going through the Steps of the SQL Reporting Services Configuration tool will recreate these jobs if you were to move the Reporting Service installation to another server. (I don't recall which step recreates the subscriptions. Just go through each pane and click "Apply.")
Depending on how you move things, you may need to backup and restore encryption keys, and you can easily end up in a state where two copies of subscription exist and are executed ( on different servers.) But in your case, where you didn't move SSRS, I'd look at the SQL Agent properties on the original server (Express) to see that the SQL agent is enabled and running, and check the history of the SQL Agent jobs, to see if there are any problems.
Related
I'm just helping out while our regular SSRS guy is away and having an issue.
There is currently a very large report that's being generated. The subscription settings for this report is to ftp the report. The Subscription status for the report currently says "Processing delivery...". I assume this to mean that it finished generating and is now trying to send the file to the ftp location. I can see that the file is there in the ftp folder but the size is still 0kb. It has been saying "Processing delivery..." for a long time now.
My question is: Is there a location (folder or sql table) I can check to see if ssrs is actually doing something? I assume it would create temporary file somewhere locally first before sending it on its way.
Check the ExecutionLog views in the ReportServer DB of your SQL Instance. There are three views which show everything from the requested format to start time, complete times, and parameters used. Take a look at the time difference between start and complete for previous runs and compare it to the running time of the current report whose complete time will be null if it is still processing.
For bonus points: setup a SSRS report based on the view and set a subscription for daily email delivery. This saves a TON of time when troubleshooting reports where users can't tell you the parameters they use or the morning reports are empty, etc.
Also, funny as it sounds, you might want to check the free space on the server that the report is output to. With no free space the report will show processing delivery for a long time. If it's FTP and you don't have control of the FTP server, still might be worth the quick phone call.
I am wanting to create a one-time SSRS shared schedule that can be altered once run, to execute again at a future point in time. The reason I am having to set-up a subscription in this way is because I need to email a set of reports based on a bespoke accounting calendar; we don't have enterprise so data-driven is not an option.
I have tested this method in the ReportServer.dbo.Subscription and Schedule tables, but have so far not managed to get it to work. I have updated the NextRunTime and StartTime columns of the Schedule table to the time I require the reports to be sent, and this appears to update on the Report Server Shared Schedules page (Next Run) but the email does not send.
Is there another table on the ReportServer database that I need to update, or is this simply not possible?
Thanks
Andy
I suggest taking a look at the article below. It details how to set up data driven subscriptions on SQL Server Standard Edition, and goes through manually activating subscriptions via SQL Server Agent.
http://www.sqlservercentral.com/articles/Development/datadrivensubscriptions/2432/
I've used if for a couple of clients and it generally works pretty well. The only thing I've since altered is increasing the timer to 10 seconds between running each data driven report.
Regards,
Jason
In reading up on this, messing abound in the tables is not supported by Microsoft. USE AT YOUR OWN RISK!
I attempted the very same thing. When you change a subscription on the front end, the ReportServer.dbo.Schedule.StartDate column changes with each edit. I tried just altering this value, but adding a value here made no difference. There was no email and when I went back to my subscription in the SSRS webpage, the original datetime value was there. So that datetime must be stored elsewhere.
I did a SQL Trace and found these Sproc's were being called. I copied out the lines that looked promising. By changing the time value #active_start_time=160400 in the last one and running the entire batch, I could get an emailed report at the desired time. But I am not content with this; because when I go back and view My Subscriptions webpage, the original datetime is still listed.
exec msdb.dbo.sp_delete_job #job_name=N'D478A346-ED05-422D-A73E-023080AD56DD'
exec msdb.dbo.sp_add_job #job_name=N'D478A346-ED05-422D-A73E-023080AD56DD',#description=N'This job is owned by a report server process. Modifying this job could result in database incompatibilities. Use Report Manager or Management Studio to update this job.',#category_id=101
exec msdb.dbo.sp_add_jobserver #job_name=N'D478A346-ED05-422D-A73E-023080AD56DD',#server_name =N'(LOCAL)'
exec msdb.dbo.sp_add_jobstep #job_name=N'D478A346-ED05-422D-A73E-023080AD56DD',#step_name=N'D478A346-ED05-422D-A73E-023080AD56DD_step_1',#command=N'exec [ReportServer$instanceDB].dbo.AddEvent #EventType=''TimedSubscription'', #EventData=''db7d7b08-3eee-4bb8-b354-b58c653b8ab6'''
exec msdb.dbo.sp_add_jobschedule #job_name=N'D478A346-ED05-422D-A73E-023080AD56DD',#name=N'Schedule_1',#freq_type=1,#active_start_date=20180405,#active_start_time=160400,#freq_subday_type=1
I have a problem with Sql Server 2005 Reporting Server where people are receiving old versions of a report whenever the report is sent through a subscription.
I've added a date to the footer of the report, build and deployed it but subscribers still receive an older report.
I am not able to find any known issue or someone with a similar problem and could use some guidance on what to do.
Check Properties -> Execution. There are options there to have the report run based on a cached copy or from a snapshot. If these options are selected, the report will be run from older data in order to increase performance. Disable these to get the latest data.
I've created a Reporting Services report and set it to run on a subscription. (SQL Server 2005, if it makes a difference.)
Unfortunately, it looks like I've made some sort of error in the parameters, and it seems to have stalled, but it isn't actually failing, just sitting on "0 processed".
I want to cancel it to fix the error, but I can't figure out how. Stopping/restarting the services seems to make no difference.
What do I need to do to stop it?
A subscription is a SQL-Server Agent job, and is given a GUID as a title. Check the SQL-Server Agent job history, and if necessary stop the job.
If you have more than one subscription, check this link for a useful View on which jobs correspond to which subscription.
http://www.sqlservercentral.com/Forums/Topic254010-150-1.aspx
I am not getting this error locally in VS 2005
or when running the report through the preview
but during subscription I start getting
ReportParameterValueNotSetException
even though all my parameters especially the one it's complaining about is set
this has started happening all of a sudden and has been working great before.
Any ideas why this might have happened
You could try deploying the report with a different name and see if subscriptions for it have the same problem. If it does not, then blame cosmic rays. It happens. In that case, delete the old report entirely from the server and then you should be able to deploy with the original name again.
If it continues to happen, then I'd start looking at what's different between running it live and running it through a subscription. Usually it's permissions related. Or perhaps the time of day the subscription fires off vs the time of day you test it live.
Is the parameter value used for the subscription hard coded, or is it based on another query?
If the latter
- does the query used for this param gen purpose work?
- does it return the correct datatype/expected data?
- does it work at the time you are running the report (database is online, has permissions set correctly)?