I've googled my issue all weekend, but can't seem to solve the problem
So basically, I have a query, when I run it manually in a query window, it works fine and my job executes, resulting in an email being sent. However, when I set up a schedule, I get the following error:
If you can't read it, the error message says,
"The job failed. The job was invoked by Schedule 9. The last step to run was step 1."
Then underneath it says,
"Executed as user 'adminName(not sa)'. Failed to initialize sqlcmd library with error number -2147467259 (SQLSTATE 42000) (Error 22050). The step failed"
So I log in with user sa, and apparently this user needs to have SQL Agent permissions in the msdb database. According to this screenshot, sa is the owner:
So since sa is the owner, it would mean it has all the SQL Agent related permissions, right? Furthermore, the code I'm using executes from the CompanyDB, so I think perhaps this may be the issue. If I look at properties, under sa, I get this window:
So the CompanyDB is unchecked for user sa, so in order to allow sa to query CompanyDB in SQL Agent, what permissions would it need? I'm assuming this is the issue, but I'm not really sure, I can't seem to figure it out, any help is greatly appreciated.
Jobs should have dbAdmin permissions. That being said, it depends on whether you wrote to the db, update, or just send the email.
The better option would be to create a webservice and call it when you want to send the email.
My SSIS Package works, but fails as a SSMS job (Error: 0xC0016016)
I am posting this question and sharing my solution to this issue as my own question because I didn't see the posed problem match the specific issue I encountered and the answers seemed to be scattered in different forum questions.
Background:
I have four SSIS packages on SQL Server 2012 that import a table from SQL Server 2008 R2, 2008, or 2005, depending on the specific package. I use a designated sql server login and password for the source database and integrated Windows security for the target database.
Within SSIS I am able to run each package without a problem.
To ensure this package ran on a schedule, I set up a SSMS job on the same server as the SSIS package. In Job step properties, I chose: SQL Server Integration Services Package > run as SQL Sever Agent Service Account > Package source: File system).
The Symptom:
When manually running the job to make sure it worked, I got an error and saw this in the Log File Viewer. This was the first of several errors, but as this was chronologically the first error, I looked into this one first.
Error: 2014-10-24 09:52:34.48
Code: 0xC0016016
Source: [Redacted -- the correct name of the table I was importing]
Description: Failed to decrypt protected XML node "DTS:Password" with
error 0x8009000B "Key not valid for use in specified state.". You may
not be authorized to access this information. This error occurs when
there is a cryptographic error. Verify that the correct key is
available.
End Error
I looked up the error code on Google and started looking at resolutions. Rather than retelling how I found the bits and pieces of the resolution, I am presenting an actionable result in sequence -- at least for me and the network infrastructure I'm working with.
In the "properties" panel of the SSIS solution (do this first) and each package in that solution, reset the "ProtectionLevel" attribute to EncryptSensitiveWithPassword and set a password. The package passwords must match the solution password.
Just a double-check, run your packages in debug mode to make sure that no other new issues arise. In my case, I needed to re-enter the sql server password for the source server database.
Rebuild your SSIS solution.
In SSMS, open your job and open the job step properties for the task in question.
Select the "Command Line" tab. A "Package Password" popup appears. Enter the password that you entered in step 1.
Select "Edit the command line manually" and place the same password from step 1 immediately after /DECRYPT.
Repeat steps 4-6 for each job step that runs this type of package.
Press the "OK" button and re-run your job.
I was able to run my job successfully after that.
SQL Server 2008 in SSMS
I'm getting this error when running a job I just created using SQL Server Agent:
Executed as user: DNA\circsrv. Database 'DN' does not exist. Make sure that the name is entered correctly. [SQLSTATE 08004] (Error 911). The step failed.
DNA is the name of a network domain, and circsrv is a valid user in that domain.
The Process for the Sql Server Agent is started by user DNA\circsrv but the job itself is owned by a different user, dn-atcore1\syncronexadmin
#owner_login_name=N'DN-ATCORE1\syncronexadmin'
(dn-atcore1 is the name of the system, and syncronexadmin is a local user on the box)
This seems like it should be simple, but I'm just not getting it.
Any ideas? Thanks for any help.
Barb
Do you have a database called 'DN'? The error states that the database does not exist. When you created the job did you set the database?
Does the database exist?
Run this code to check.
-- main database
use master;
go
-- does the db exist?
select *
from sys.sysdatabases
where name like 'DN%'
go
If it does not exist, you have bigger issues here!
Time to find a backup to restore from ...
Have just deployed my Project on to my reporting Server.
I have multiple datasets which are referencing views which exist on the db on that server.
When I try to go into any report part I am getting this message:
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'dataset1'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
Can anyone help?
I enabled remote errors to pinpoint the problem.
I identified that a column in a particular dataset (one of my views) was throwing an error.
So using a tool "SQL Delta", I compared the development version of the database with the live version on the reporting server. I noticed that one of the views had an extra column on the development server, that was not on the live version of the db.
SQL Delta generated the script I needed to run to update the view on my live db.
I ran this script, re-ran the report, everything worked.
I encountered a similar error message. I was able to fix it without enabling remote errors.
In Report Builder 3.0, when I used the Run button to run the report, an error alert appeared, saying
An error has occurred during report processing. (rsProcessingAborted)
[OK] [Details...]
Pressing the details button gave me a text box where I saw this text:
For more information about this error navigate to the report server
on the local server machine, or enable remote errors
----------------------------
Query execution failed for dataset 'DataSet1'. (rsErrorExecutingCommand)
I was confused and frustrated, because my report did not have a dataset named 'DataSet1'. I even opened the .rdl file in a text editor to be sure. After a while, I noticed that there was more text in the text box below what I could read. The full error message was:
For more information about this error navigate to the report server
on the local server machine, or enable remote errors
----------------------------
Query execution failed for dataset 'DataSet1'. (rsErrorExecutingCommand)
----------------------------
The execution failed for the shared data set 'CustomerDetailsDataSet'.
(rsDataSetExecutionError)
----------------------------
An error has occurred during report processing. (rsProcessingAborted)
I did have a shared dataset named 'CustomerDetailsDataSet'. I opened the query (which was a full SQL query entered in text mode) in SQL Server Management Studio, and ran it there. I got error messages which clearly pointed to a certain table, where a column I had been using had been renamed and changed.
From that point, it was straightforward to modify my query so that it worked with the new column, then paste that modification into the shared dataset 'CustomerDetailsDataSet', and then nudge the report in Report Builder to recognise the change to the shared dataset.
After this fix, my reports no longer triggered this error.
Like many others here, I had the same error. In my case it was because the execute permission was denied on a stored procedure it used. It was resolved when the user associated with the data source was given that permission.
I experienced the same issue, it was related to security not being granted to part of the tables. review your user has access to the databases/ tables/views/functions etc used by the report.
The solution for me came from GShenanigan:
You'll need to check out your log files on the SSRS server for more detail. They'll be somewhere like: "C:\Program Files (x86)\Microsoft SQL Server\MSRS10_50.DEV\Reporting Services\LogFiles\"
I was able to find a permissions problem on a database table referenced by the view that was not the same one as the where the view was. I had been focused on permissions on the view's database so this helped pinpoint where the error was.
I just dealt with this same issue. Make sure your query lists the full source name, using no shortcuts. Visual Studio can recognize the shortcuts, but your reporting services application may not be able to recognize which tables your data should be coming from. Hope that helps.
I had the similar issue showing the error
For more information about this error navigate to the report server on
the local server machine, or enable remote errors Query execution
failed for dataset 'PrintInvoice'.
Solution:
1) The error may be with the dataset in some cases, you can always check if the dataset is populating the exact data you are expecting by going to the dataset properties and choosing 'Query Designer' and try 'Run', If you can successfully able to pull the fields you are expecting, then you can be sure that there isn't any problem with the dataset, which takes us to next solution.
2) Even though the error message says "Query Failed Execution for the dataset", another probable chances are with the datasource connection, make sure you have connected to the correct datasource that has the tables you need and you have permissions to access that datasource.
In my situation, I created a new SSRS report and new stored procedure for the dataset. I forgot to add the stored procedure to the database role that had permission to execute it. Once I added the permissions to SQL database role with EXECUTE, all was fine!
The error message encountered by the user was "An error occurred during client rendering. An error has occurred during report processing (rsProcessingAborted). Query execution failed for dataset "DataSet1'. (rsErrorExecutingCommand) For more information..."
Very grateful I found this great post. As for my case, the user executing the stored procedure did not have EXECUTE permissions. The solution was to grant EXECUTE permissions for the user within the stored procedure by adding below code to the end of the stored procedure.
GRANT EXECUTE ON dbo.StoredProcNameHere TO UsernameRunningreports
GO
I also had a very similar issue with a very similar error message. My issue was that the database could not be connected to. In our case, we have mirrored databases and the connection string did not specify the Failover Partner. So when the database couldn't connect, it never went to the mirror and was throwing this error. Once I specified the Failover Partner in the connection string for my datasource, it resolved the issue.
BIGHAP: A SIMPLE WORK AROUND FOR THIS ISSUE.
I ran into the same problem when working with SharePoint lists as the DataSource, and read the blogs above which were very helpful. I had made changes in both the DataSource and Data object names and query fields in Visual Studio and the query worked in visual Studio. I was able to deploy the report to SharePoint but when I tried to open it I received the same error.
I guessed that the issue was that I needed to redeploy both the DataSource and the DataSet to SharePoint so that that changes in the rendering tools were all synced.
I redeployed the DataSource, DataSet and the Report to sharePoint and it worked.
As one of the blogs stated, although visual studio allowed the changes I made in the dataset and datasource, if you have not set visual studio to automatically redeploy datasource and dataset when you deploy the report(which can be dangerous, because this can affect other reports which share these objects) this error can occur.
So, of course the fix is that in this case you have to redeploy datasource, dataset and Report to resolve the issue.
I was also facing the same issue - I checked below things to fix this issue,
If you have recently changed pointing database-name in data-source
then first check that all the store procedures for that report exist
on changed database.
If there are multiple sub reports on main report then make sure each
report individually running perfectly.
Also check security panel - user must have access to the databases/
tables/views/functions for that report.
Sometimes, we also need to check dataset1 - store procedure. As if you are trying to show the report with user1 and if this user doesn't have the access(rights) of provided (dataset1 database) database then it will throw the same error as above so must check the user have access of dbreader in SQL Server.
Also, if that store procedure contains some other database (Database2) like
Select * from XYZ inner join Database2..Table1 on ... where...
Then user must have the access of this database too.
Note: you can check log files on this path for more details,
C:\Program Files\Microsoft SQL Server\MSRS11.SQLEXPRESS\Reporting Services
I got same error but this worked and solved my problem
If report is connected to Analysis server then give required permission to the user (who is accessing reporting server to view the the reports) in your model of analysis server.
To do this add user in roles of model or cube and deploy the model to your analysis server.
Using SSRS, Report Builder 3.0, MSSQL 2008 and query to an Oracle 11G database,
I found that the oracle stored procedure ran well, produced consistent results with no errors. When I tried bringing the data into SSRS, I got the error as listed in OP's query. I found that the data loaded and displayed only if I removed the parameters (not a good idea).
On Further examination, I found that under dataset properties>parameters I had set the start date to parameterName P_Start and parameter Value to #P_Start.
Adding the Parameter value as [#P_Start] cleared the problem, and the data loads well, with parameters in place.
This problem was caused by an orphaned SQL Login. I ran my favorite sp_fixusers script and the error was resolved. The suggestion above to look at the logs was a good one...and it led me to my answer.
This might be the permission issue for your view or store procedure
In addition to the above answers, it could be due to a missing SQL stored-procedure or SQL function. For example, this could be due to the function not migrating from a non-prod region to the production (prod) region.
Removing all comments from the Select Query fixed this for me. My dataset was working in the Preview but when I went to Design/Query Designer and and tried the query there I was getting ORA-01006;bind variable does not exist. After removing all comments from the select it worked.
I'm trying to drop a database from PgAdmin 3 and I get this error message:
ERROR: can't delete current database
SQL state: 55006
how can I force the delete/fix this error, of this database?
Quick fix in PgAdmin: just create another empty database. Select it. Delete the first one. Voila.
You can also connect to the command line without selecting a specific database, and drop your database.
The problem here is not that other users are connected to the database, but that you are.
This post by Leeladharan Achar was helpful for me in working with this error.
It essentially boils down to:
SELECT pg_terminate_backend(pg_stat_activity.pid)
FROM pg_stat_activity
WHERE pg_stat_activity.datname = 'target_db'
AND pid <> pg_backend_pid();
DROP DATABASE 'target_db';
Simplest fix for this is restart the postgresql. After that You can get rid of database!
If you want to use the pgAdmin4 interface, you have to first delete/drop the db, then, before waiting for the error, you have to immediatelly disconnect from the same database, then it gets deleted without problem.
Instead of creating new database he can simply connect to postgres database, which is created by default in all new PostgreSQL installations. And even if it is not there - template1 should be always there.
The best method to drop user is below mentioned
Like i have a user name is "X" and it have access permission to database name : "Test" .
And now we are created connection with "Test" database
If we try: drop user "X" this will be definality show below mentioned error:
ERROR: user "X" cannot be dropped because the user has a privilege on some object SQL State=55006
First of all connection should not be created with "Test" db.because it currently use so we are not able to delete the user.
create connection with any of database except eg "Test"
Now again try
drop user test
It should be worked fine on my side,let me know if you are facing issue on your side
The easiest and perhaps the neatest fix is to go to services and stop the PostgreSQL server and then start it, and then run the drop database yourdbname; command again. That should disconnect any sessions and allow you to drop the current database.