I'm currently unable to email out time based subscription reports from SSRS on a new SQL Server 2012 installation on Server 2012.
I receive the following error in the SSRS LogFiles
schedule!WindowsService_5!dc4!10/14/2013-10:01:09:: i INFO: Handling Event TimedSubscription with data 1a762da1-75ab-4c46-b989-471185553304.
library!WindowsService_5!dc4!10/14/2013-10:01:09:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerStorageException: , An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database.;
library!WindowsService_5!dc4!10/14/2013-10:01:09:: w WARN: Transaction rollback was not executed connection is invalid
schedule!WindowsService_5!dc4!10/14/2013-10:01:09:: i INFO: Error processing event 'TimedSubscription', data = 1a762da1-75ab-4c46-b989-471185553304, error = Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerStorageException: An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database. ---> System.Data.SqlClient.SqlException: Invalid object name 'ReportServerTempDB.dbo.ExecutionCache'.
Databases were migrated from SQL 2008, this was done by a third party and I'm unsure if something was overlooked.
Any assistance would be greatly appreciated.
Thank you.
Dane
This thread seems to address your issue.
http://www.sqlservercentral.com/Forums/Topic553765-147-1.aspx
Please do a modicum of research before posting error messages.
From the Link
"
After much consternation, I have found a trigger referencing the invalid object. Trigger [Schedule_UpdateExpiration] on ReportServer table Schedule has the offending reference in it. In test, I altered this trigger to reference the correct report server tempdb and now subscriptions appear to be working properly. So far I have found nothing else broken."
AND
"If anyone is looking for a quick answer then here is what I did to solve my problem:
Updated trigger on dbo.schedule to reference the correct tempdb.
Scripted all stored procedures with their permissions onto a new query then "find and replaced" all instances of the old tempdb with the new one. "
After a while searching for a solution to fix this issue, I found that this is caused by the jobs definition of SQL Server Agent was not fully migrated to the new service. For every subscription created in SSRS, there is an associated job defined in SQL Server Agent. For services reply heavily on report delivery via subscriptions, it's best to export those jobs definition and import them into the new server.
Daniel E. answer is Correct.
I have spend a lot of time to find it and the error I am getting while updating the existing subscriptions
“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)”
when i search online with the above error, i couldn't manage to fix it. after a long time i found the tigger is pointing to old database.
Temp database in the below: [ReportServerTempDB]
after updating to correct tempDB all started working fine.
ALTER TRIGGER [dbo].[Schedule_UpdateExpiration] ON [dbo].[Schedule]
AFTER UPDATE
AS
UPDATE
EC
SET
AbsoluteExpiration = I.NextRunTime
FROM
[ReportServerTempDB].dbo.ExecutionCache AS EC
INNER JOIN ReportSchedule AS RS ON EC.ReportID = RS.ReportID
INNER JOIN inserted AS I ON RS.ScheduleID = I.ScheduleID AND RS.ReportAction = 3
Related
I've been running into an issue in R Studio with a SQL connection.
We've had an on-prem SQL Server that's been upgraded over the years, and a colleague that set it up no longer is with the organization.
We also have an Azure Server that's loaded with a SQL Server as well that was much more recently set up before they departed.
We have a GUI program we're currently developing, and one of the early steps is a SQL Login connection for the user where the variable is declared (db_user) and changes with their login and passes the password correctly within system variables defined in .Renviron as posted on RStudio's site for references.
Our initial connection string looks like this, and this is the line of code that starts the connection and where I believe the issue may lie first:
db_conn_onprem <- DBI::dbConnect(odbc::odbc(),
Driver = "SQL Server",
Server = Sys.getenv("server"),
Database = Sys.getenv("database"),
UID = Sys.getenv("db_user"),
PWD = Sys.getenv("PWD")
Whenever the Azure connection succeeds, it connects as dbo#Azure\Azure vs On-Prem's guest#Server\Server.
(I can't post in-line screenshots yet)
On-Prem Connection Screenshot: https://i.ibb.co/PmbGt5y/RStudio-SQL.png
Azure Connection Screenshot: https://i.ibb.co/WFY3FqZ/azure1.png
I feel this is something dbo-related since that's where the connection drops.
(variable names anonymized)
Now for the issue:
Whenever we attempt to run a series of queries, our on-prem errors out with this:
Error: nanodbc/nanodbc.cpp:1655: 42000: [Microsoft][SQL Server][SQL Server]Cannot execute as the server principal because the principal "db_user" does not exist, this type of principal cannot be impersonated, or you do not have permission.
<SQL> 'EXECUTE AS LOGIN = 'db_user' SELECT name FROM master.sys.sysdatabases WHERE dbid > 4 AND HAS_DBACCESS(name) = 1 ORDER BY name ASC'
However, run the exact same procedure on the SQL Server in Azure with relatively no major configuration, and it succeeds.
Here's the SQL Code we run:
EXECUTE AS LOGIN = 'db_user' SELECT name
FROM master.sys.sysdatabases
WHERE dbid > 4
AND HAS_DBACCESS(name) = 1
ORDER BY name ASC
I feel like I've exhausted my resources for this, first I thought it was the initial R code or possibly SQL Drivers, however I don't believe that to be the issue since the SQL driver pulls a list of names in R Studio in the Connections context menu, but bounces back the error when attempting to complete the query.
Whenever I'm searching errors for references for this error, I see
Cannot execute as the server principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
Listed as the most commonly related error for the one I'm experiencing, however I've tried a number of those (From blank DB ownerships to unrelated solutions), but I've mostly hit a wall here.
Any assistance would be greatly appreciated.
I feel this is something dbo-related since that's where the connection drops, but I have no clue where to continue going on this issue.
Yep.
This
EXECUTE AS LOGIN = 'db_user'
requires impersonate permission for the login. Which the error message is clearly telling you. It's unclear why you want to impersonate that login instead of simply connecting as the login to begin with.
I'm using the SQL Connector in Azure Logic Apps to connect to our Azure SQL Database to perform queries, update tables, and execute stored procedures. After several months of developing logic apps, I'm seeing the below error message when using the SQL Connector "Execute Stored Procedure (V2)". I'm only encountering this error with this specific connector. All the other connectors work just fine. Has anyone encountered this error before and had success troubleshooting?
Error:
Could not retrieve values. Error code: 'BadRequest', Message: 'The value's length for key 'application name' exceeds it's limit of '128'.
clientRequestId: 'XXXXX'. More diagnostic information: x-ms-client-request-id is 'XXXXX'.
Just had a call with Microsoft Support and got confirmation: this is the global issue in the SQL connector of LogicApp. They are working on this to fix, no ETA for now.
Update: should be fixed from around 29.03.2022 03:00 CET
Hi I delete all publications and subscriptions on sql server 2008 . Then try to disabling publishing and distribution for reconfigure replication but have an error :
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Invalid object name 'dbo.sysmergesubscriptions'.
Changed database context to 'master'. (Microsoft SQL Server, Error: 208) Ho solve it ?
One thing you can do is: create that object by yourself. Most likely there would be more than one table/view missing. Just script those missing objects from another database (for example, develop environment) and create them in your production box.
I'm trying to create a new development branch from main (our first branch) but with no luck.
I've tried google but google doesn't seem to want to help me today...
The error i receive is this:
A database error occurred (SQL error 8152) ---> String or binary data would be truncated.
SRV-TFS.TfsVersionControl..prc_PendBranch: Database Update Failure - Error 8152 executing INSERT statement for tbl_PendingChange
please check the name of your branch. I think its too long that TFS database allows.
I have a report that runs a stored procedure that takes about an hour to run.
After about 30 minutes I get this error message on the report body:
An error has occurred during report processing.
Query execution failed for data set 'DEV'.
A severe error occurred on the current command. The results, if any, should be discarded. Operation cancelled by user.
The same stored procedure runs fine when I run it from SQL Server management studio (with the same login credentials the report runs under).
Any ideas what could be causing this? I tried increasing the timeout value on the report but that didn't help.
This just sounds like a timeout. May I suggest you don't base a SSRS report on a stored proc that takes so long to run. You could schedule a daily job to populate a table (or tables) containing this report data and point the report at this table. That way it doesn't have to recalculate the data every time.
You can find the logs in your SQL Server installation directory. example: C:\Program Files\Microsoft SQL Server\MSRS10.REPORTING\Reporting Services\LogFiles
This might help.
http://blogs.msdn.com/b/jgalla/archive/2006/10/11/session-timeout-during-execution.aspx
Check your connection string for the report. I got this error when I had used a malformed connection string. i.e. I had "Server=" when I should have had "Data Source=".