Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

2008 Subscription Error Expand / Collapse
Author
Message
Posted Monday, March 23, 2009 1:50 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, June 13, 2011 4:12 PM
Points: 67, Visits: 137
Recently, we migrated two instances of RS 2005 to RS 2008. In one of the instances we encounter the following error when clicking 'OK' to create/modify a report subscription.

An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database. (rsReportServerDatabaseError) Get Online Help Invalid object name 'ReportServerTESTTempDB.dbo.ExecutionCache'.

Note: We have change the name of this instance. Thus, the object referred to above, is from the 2005 database. Whatever action is occuring to use this object, it should be looking for 'ReportServerStagingTempDB.dbo.ExecutionCache'

Was it a mistake to change the names? How might we be able to resolve this?

I'm more than willing to provide more information if necessary. Any help provided will be much appreciated. I thank you in advance.

Joey
Post #681805
Posted Thursday, March 26, 2009 2:42 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, June 13, 2011 4:12 PM
Points: 67, Visits: 137
We found the root cause of the problem and a solution.

There exists a trigger, Schedule_UpdateExpiration, on the ReportServer.Schedule table that references the "TempDB" dbo.ExecutionCache table. We altered the trigger to point to the table with the appropriate fully qualified name.

So far we have yet to notice any other objects that point to the old db name, thus everything is working properly. However, we will keep our fingers crossed.

The thread at the following link was a big help.

http://www.sqlservercentral.com/Forums/Topic553765-147-1.aspx#bm670251
Post #684600
Posted Wednesday, April 01, 2009 2:41 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, April 20, 2012 1:53 PM
Points: 1, Visits: 26
Thanks Soo Much. I had a similar issue and got around it using the above approach
Post #688376
Posted Monday, September 20, 2010 6:37 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, April 11, 2014 2:13 PM
Points: 266, Visits: 728
Excellent!!!!

I had the same issue and just found this thread. I changed the name in the trigger to reference the new server and I am back in business.



Post #989858
Posted Monday, December 13, 2010 8:20 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, January 28, 2014 1:11 PM
Points: 92, Visits: 569
Frustrating. Reading through this thread a smile grew on my face as I realised I had found the resolution to my issues.

Alas not. I have exactly the same problem as those mentioned here, but not the same reason. I have not changed instance names etc. Indeed this has occured on a deployment that has been working for months before. I left to go on paternity leave for 2 weeks, returned to find that I could not amend any subscriptions, and whilst the job in SA appeared to be running properly, no reports were being emailed out.

I get the same message as others here. I did check, for happenstance, to see if my triggers had changed, but mine do reference the correct locations etc.

I don't hold out much hope, but if anyone can help with that i'd be eternally greatful.

thanks.
Post #1033838
Posted Thursday, December 23, 2010 2:52 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, February 04, 2014 5:40 AM
Points: 10, Visits: 184
Hi There,

We had a similar problem and when we analyzed the issue we found that there were two different SQL Agent Jobs with the same name assiciated with the same schedule. When we deleted those SQL Agent Jobs & Re-Created the Schedule, it solved the problem.

Hope it helps!


Dattatrey Sindol
Blog: Datta's Ramblings on Business Intelligence 'N' Life

This information is provided "AS IS" with no warranties, and confers no rights.
Post #1038660
Posted Saturday, October 15, 2011 7:49 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, April 04, 2014 12:45 PM
Points: 2, Visits: 49
Thanks. The database on our 2005 server was RSDB and RSDBTemp, and we renamed the ReportServer and ReportServerTempDB on 2008, and we got this problem. It worked. Thanks!
Post #1190913
Posted Wednesday, April 04, 2012 10:38 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, October 25, 2013 6:10 PM
Points: 1, Visits: 24
Thanks so much!!!
Post #1278234
Posted Monday, September 09, 2013 10:08 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 10, 2013 8:31 AM
Points: 7, Visits: 34
Completely different cause and resolution to this problem for me:


When I grant sysadmin to my SSRS login it resolves the issue (obviously not a solution). Double-triple-quadruple checked all RSExec role permissions. All correct. Grasping at straws for hours. Finally noticed the ownership on all of the subscription jobs was odd. It was owned by a domain user account that no longer exists.


Several weeks ago we had switched the service account for SSRS to a new AD account (new naming convention, old account deleted). I cannot find any documentation from MS regarding updating ownership of subscription / jobs when modifying the SSRS Service account. Regardless, changing the ownership to = the new AD account resolves the issue.


Seems to me, this is a deficiency in SSRS config manager or to say the least, lacking / undocumented feature. Maybe I'm just a silly DBA and this should be a no-brainer. Seems to me when you log into the config manager and change the user account, you should be forced to do this via a dbo / sys admin user on the SQL Server. It should then automatically change the ownership for you.

Post #1492853
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse