I've recently copied an SSRS instance from SQL 2008 R2 to a new SQL 2012 instance. I performed a backup/restore on the report server DB and encryption key and have configured the service/execution accounts etc. I can run reports via report manager without incident and I can create new subscriptions the same way which run fine.
However, whenever one of the previously existing subscriptions (set up under R2) is due to run, it fails with the following error:
Microsoft.ReportingServices.Diagnostics.Utilities.AuthorizationExtensionException: An error occurred when invoking the authorization extension. ---> System.ArgumentNullException: SafeHandle cannot be null.
The suggestion seems to be that this is related to custom security components, but we don't have any. We do have a custom DLL for other purposes, but it isn't even being invoked when the subscriptions in question run, so it's highly unlikely it's that. CAS is configured for this DLL.
I'm really looking for suggestions on where to start looking to resolve this error, as I'm out of ideas on what to try!
I posted the same question on MSDN and got an answer suggesting it could be that the subscriptions that were copied over from the old server were created by local users that don't exist on the new server.
After some investigation, this turned out to be the case. It seems that SSRS needs the subscription creator (OwnerID field in the Subscriptions table in the Report Server DB) to be a valid account, as it must perform some sort of verification when it attempts to run the subscription.
Once I changed this to a valid domain account (a local account would work just as well), the subscriptions all work fine.
Related
What could cause one user to be initiating an old version of the report?
I have a report that runs perfectly when logged directly on the reporting services server.
When run from the LAN it gives an error that one of the parameter data sets execution failed. The error message shows that the parameter is pointing to a data set that was used in the report months ago but is no longer currently used. Looking at the properties of the report in reporting services everything is pointed to a valid shared data set.
The .rdl file has a connection string saved in it. This is what you connect to during development and it is the default connection. When you upload the file to the reporting services server, you have the option of overriding that and pointing it to a shared data source. In other words, the "old" data source has always been built into that .rdl file (you can look at the XML to confirm this), but it is being overridden on the server.
Hope this helps clear up the confusion.
have a strange one. We are running Sql Server 11.0.3000. The report is giving an error
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'Audit_Detail'. (rsErrorExecutingCommand)
Invalid object name 'dbAudit.tblRangeReport'.
The thing is, the report uses 3 stored procs to go after data in a database called dbSalarySurvey. The three sp's do not mention the dbAudit.tblRangeReport. There are no functions or views in the 3 sp's that access that table. Further more, if i run the report in VS 2012 the report runs. If i run profiler on the dbAudit table when VS runs the report, the report does not query the dbAudit table. Only when running the report from the web browser do i get this error. This more detailed version of the error come from running the report on the Sql Server REporting services computer.
I have tried restarting the reporting services service. We have also deleted this one report from the reporting services server and republished it. Have also tried to republish the dataset. Other reports in this project that use the datasource and the same tables run.
Anyway, was wondering if anyone had any sugguestions.
Thanks
shannon
It's fixed. it was a pebkak error in the stored proc. It's really strange though. Honest to goodness, the proc was running in my dev env but not when running from a browser. I had already checked profiler like was suggested below and done the xml scan too. In the end.. just missed it i guess.
You need to trace the SQL to determine.
Are you connecting to the right database?
Are the procs you expecting to see, the ones actually being run?
The procs you are running are correct?
Open SQL Server Profiler
Start New Trace
Click Event Selection, Select the following events
Click - Show All columns
Go into Column Filters
and filter on your DB, and possibly even your login name (the login name of the SSRS server)
Once you've done that, call your report and look to make sure all the procs are called that you expect. Track issues from there.
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.
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.
We have an environment where each of our clients has their own database instance (with identical schemas, for all intents and purposes). We have a dashboard application where clients can login to perform CRUD operations on data in their specific database. We use a single code-first EF model for interacting with the databases. (For whatever client is being viewed, we simply pass that client's database's connection string when instantiating the DbContext.)
However, the database instances are a mix of SQL Server 2005 and 2008. (I'm pretty sure this is the root of the problem we're seeing.)
On a particular page, we've begun to see the following error occur:
The version of SQL Server in use does not support datatype 'datetime2'.
From Googling and StackOverflowing, I've come to the conclusion that it's probably due to a misconfigured ProviderManifestToken on the DbContext.
However, the error is sporadic. Based on production error logs, I can view the same client for which the error occurred and perform the same CRUD operations without getting the error.
I'm at a loss.
Is it even possible to programmatically set the ProviderManifestToken? Or maybe the default connection factory isn't properly setting it (and there's something I can do to help it along)? Or am I way off base? Any ideas?
By the way...
The entity that the error is occurring on has 2 datetime columns, both of which are nullable (and the most recent error had null and Jan 13, 2012 as its values for those fields, so I'm pretty sure that this answer about ensuring that the values are within datetime's range doesn't apply.
Well, no solution yet. But we figured out a workaround for now.
If we restart the app pool, then immediately visit the client dashboard for a 2008-backed client, EF will generate and cache a mapping based on SQL Server 2008 constraints and all 2008-backed dashboards work just fine but 2005-backed dashboards fail on writes with the datetime2 error.
However, if we restart the app pool, then immediately visit a 2005-backed client dashboard, EF will generate and cache a mapping based on SQL Server 2005 constraints (which allows the model to work with both 2005 and 2008 database instances).
So, basically, our publish process now has the extra step of immediately visiting a 2005-backed dashboard.
Thank you for posting this. I had the same problem with a console app that visited a SQL2008 DB than a SQL2005 DB and had the same problem. I switched it so it went SQL2005 first, than SQL2008 and the problem went away. I am also using EF code first.