I am running a SQL Server Job and I'm getting the following error.
The job failed. The job was invoked by the user sa. The last step to run was step 1. Executed as user. NT service\SQLAgent$SQL2014. Miscrosoft (R) SQL Server Execute Package Utility version 12.0.50000.0 for 32-bit.
Can anyone tell me why this happening?
Based on your pastebin of the error, it looks like the oledb source connection in your package is setup to login as sa. On a side note, this is bad practice...
This error usually indicates one of two things. Either the server instance is setup to only allow windows auth or the password entered in the connection manager for user sa is not correct.
Related
I am using SQL SERVER 2008 R2 and I have a job which runs a DTS daily. When I try to execute the DTS package it works but when I try to use the scheduled job it returns the error:
Error:
-2147467259 (80004005); Provider Error: 18452 (4814) Error string: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. Error source: Microsoft OLE DB Provider for SQL Server Help file: Help context: 0. Process Exit Code 1. The step failed.
How can I solve that?
Follow the below steps:
1. Start > Programs > Microsoft SQL Server 2008 > SQL Server Management Studio.
2. In the Object Explorer, right-click the Server and select Properties.
3. In the Server Properties dialog box select the Security page.
4. Under Server authentication, select SQL Server and Windows Authentication Mode.
Then restart the server.
For further reference check this.
I stumbled across this issue and spent lot of time.
Finally found the issue is not in any user settings but my publish settings are overriding my connection string.
In web deploy settings there is an option to override your web.config connection string. Either untick that option or place the correct connection string.
For more details see this post https://dba.stackexchange.com/a/141243
I am placing this answer in case anyone gets stuck like me. :)
I have the following problem. I have a SSIS Package that works fine when I execute it from visual studio, but when I execute it through the SQL Server Agent it gives me this error (I have it in spanish so I'll translate it and it might be a bit different from the normal message):
"Can't find connection "{(the id of one of my database connections)}". The Connections collection returns this error when it can't find the specific connection element.".
The SQLSERVERAGENT user has privilegies in the project's folder.
When planning the execution, I used the package file as a origin, if that has something to do.
I ran out of ideas and don't know what to do. Any help would be greatly appreciated.
Thanks in advance,
Khor
I finally made it work.
The problem was that the user who created the packages had permissions on the server I was accessing with the ODBC to but the SQLSERVERAGENT user didn't.
I changed the user in the SQL Server Agent service from SQLSERVERAGENT to the user who created the packages to make sure that this was the problem and it worked fine, so the solution is either leave the service with this user or give permission on the other server to the SQLSERVERAGENT user.
I am working on SQL Server 2008 R2 Express, when I am using SQL Server debugging feature from client pc, this error occurs:
The EXECUTE permission was denied on the object 'sp_enable_sql_debug', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)
My user name is 'HALI' and permission is assigned to me is 'public' and 'db_Owner',
now after this error I have assigned all permissions available. And all server roles.
Now at this time I got new error message,
Error HRESULT E_FAIL has been returned from a call to a COM component. (mscorlib)
Now what the solution would be for this error.
I am not sure if disabling firewall is enough. if the user has sysadmin permissions and still getting this error means client is not able to connect to server in debugging mode. check this TCP and UDP ports are correctly open.
SQL remote debugging configuration
EDIT:1
I am sure you must have also googled a lot and tried to find out about the error messages.
What I have found so far is the Error in the OP you mentioned is misleading and from that error, we cannot tell what exactly is wrong or what to look next. But as you replied in the comments, after making changes to enable Remote Debugger; the mentioned error is more clear and I feel that proper permission is still an issue. Plenty of other suggestion you also might have tried so far, but if you haven’t done this, let's try one more time:
In one of the comments I mentioned you to try login using the windows user.
Now Keep the settings you already did for TCP ports, Firewall Exception, etc… explained in the above link.
you have windows 2012 server where you installed DB server. and windows 8 Prof where you have DB client and you connecting through SSMS. Now I believe both machines are in the same domain. Let’s say domain XYZ. You must have windows login on server, let’s say it is “XYZ\HALI” using which you can login to the Windows Server. log in and make sure that login also exists in SQL SERVER with sysadmin permission. Because client machine is also in same domain make sure you have logged in into the client machine using same user “XYZ\HALI”. Now start SSMS and choose windows authentication instead of SQL SERVER authentication. Try to start Debugging T-SQL code now.
if client and server machines are not in the same domain then we have to register server name on client machine as Linked Server, impersonate the login/user as local and then try the debugging.
Edit:2
I encountered this problem after generating a SQL 2012 script and running it in a SQL 2008 R2 database.
After some research, I found out that my target SQL 2008 R2 was running on a 32-bit OS which supports a file of up to 2GB in size. So I saved the script as C:\myScript.sql and successfully executed it in a command prompt with these steps:
Open a command prompt window.
In the command prompt window, type:
sqlcmd -S myServer\instanceName –U yourUserName –P yourPassword -i C:\myScript.sql
where myServer\instanceName is the instance name. Supply the user name and password for SQL server login, and finally the path of the file as indicated.
Press Enter.
References:
sqlcmd Utility | Microsoft Docs
Use the sqlcmd Utility | Microsoft Docs
The few times I've run across that error, it's always been firewall related. Are you working on a remote server, or your local machine? (Parenthetically, be careful assigning all possible roles. Some of them are ones you absolutely don't want. The one you need for SQL debugging is sysadmin - try disabling the rest of the roles you checked off and just assigning that one.)
Debugging procs is always a pain. This ASP.NET post helped me out substantially awhile ago.
I'm testing my app who connects to my DB and starts executing SQL sentences. After a few thousand querys I get the following error from Visual Studio: "Login error for user xxxxx" and in different points of the code.
The SQL Server's authentication is "SQL Server and Windows Authentication mode".
Any help on this,
Thanks.
If you're using SQL Server 2005 then maybe FIX: Error message when you try to use a SQL Server authenticated login to log on to an instance of SQL Server 2005: "Logon error: 18456" will help.
I think sr.u tries to say that the error occurs at various points of the code, after a number, maybe many successful executions.
So I'd rather suspect that he or she just opens a new connection for every SQL command and simply forgets to close it. Or something like this.
For now I've fixed it by running half of the SQL statements with another (identical) connection.
SQL Server Reporting Services, in SSRS it seems like Schedules never fire, however a look at the SQL Agent reveals a permission issue related to not being able to resolve a user account.
Seems SQL Agent does not rely on caching or whatever voodoo Windows magically works.
link text
Fix is listed here...
edit --
Above is the fix I used to workaround this issue, has any one found any other work arounds or resolutions to this issue?
It seems that by default the SSRS Generated Schedules are run as this phantom user account. How do I change this default? Is SSRS creating the jobs as the user the service runs as?
Thanks Remus
I was running into the same issue. Here is how I fixed it.
Problem description
When setting an SSRS report subscription to run at a given time, I would wait for the time to pass and then find that the "Last Run" timestamp did not change. My subscription appears not to have run.
Relevant troubleshooting info
SSRS report subscriptions are executed as SQL Jobs that the Report Server web UI creates for you behind the scenes.
When looking at the job that was created for my report subscription, I saw that it always failed with the error:
The job failed. Unable to determine if the owner (domain\userName) of job 0814588B-D590-4C45-A304-6086D5C1F559 has server access (reason: Could not obtain information about Windows NT group/user 'domain\userName', error code 0x5. [SQLSTATE 42000] (Error 15404)).
In the Sql Server Configuration Manager I could see that the "SQL Server Reporting Services" service was configured to run using an AD user account.
In the Sql Server Configuration Manager I could see that the "SQL Server" service was configured to run using a local Windows account.
As #Remus Resanu pointed out, the SQL error 15404 refers to an exception when EXECUTE AS context cannot be impersonated.
Solution
Bingo! #4 and #5 are the key to the problem. The SQL Server service (a local Windows user account) was trying to authenticate the user "domain\userName" in AD, which it could not do because it does not have the right/permission to access AD resources.
I changed the SQL Server service to us an AD user account, restarted the SQL Server and SQL Server Agent services, re-ran the SQL job and, blamo, success!
15404 is the exception when EXECUTE AS context cannot be impersonated. Reasons for these error are plenty. The most common reasons are:
when the SQL Server instance does not have access to the AD server because is running as a local user or as 'local service' (this would have an error code 0x5, ACCESS_DENIED)
when the SQL Server is asked to impersonate an unknown user, like an user from a domain the SQL Server has not idea about (this would have the error code 0x54b, ERROR_NO_SUCH_DOMAIN)
The proper solution is always dependent on the error code, which is the OS error when trying to obtain the impersonated user identity token: one searches first for the error code in the System Error Codes table (or fires up windbg, does a loopback non-invasive kernel debug connection and goes !error, which is what I prefer cause is faster...).
So, John... do you actually have a question, or just posted a random piece of partial information?
I did 2 things and it's now working.
1) Go to "SQL Server Configuration", change the "SQL Server Agent" - "Log On As" to match the "SQL Server" above.
2) Secondly, open "Microsoft SQL Management Studio", at the "SQL Server Agent", expand the "Jobs" and you should be able to see your created job. Right click on it and go to "Properties".
3) Change the owner to also match the "SQL Server Agent" above.
After, I'm able to execute the Maintenance Plan without any issue.
Just follow this steps in images