My stored procedure in SQL Server 2008 R2 runs queries on several local and several remote databases (via linked servers) and works fine when I exec it while in SSMS.
When I run the same exec from a sqlcmd script the linked server connections fail with error...
Cannot initialize the data source object of OLE DB provider "SQLNCLI10" for linked server "BLAHBLAH.BLAH.BLAH.ORG".
The sqlcmd invocation is...
sqlcmd -U sa -P myPassword-S localhost
-i C:\SS_DB_TRACK\job_run_periodic_nightly.sql
-o C:\SS_DB_TRACK\job_run_periodic_nightly.lst
Thanks much if someone can advise me on how to get the sqlcmd script to work.
Jay
The difference you are seeing is most likely due to running in a different security context. The sqlcmd parameters you have show it logging in as sa (usually not a good idea). So if you are seeing different behavior in SSMS then you are probably logging into that same server using Windows Authentication. If you logged into that server, via SSMS, using SQL Server Authentication as sa, then you should see the same error. Along those same lines, if you switch the sqlcmd authentication to be -E for Trusted Connection (i.e. Windows Authentication), then it should work (and it appears that this did, in fact, work). If you prefer that this process not be run under your security context then you need to check the security setup of the Linked Server to see why the two different Logins get different responses from using the Linked Server. Ideally you would use another non-sa Login for the process, possibly even create a Login (that is not a member of the sysadmin server role ;-) to handle this process.
Instead of "LinkedServerName" try [LinkedServerName]
Related
We have some deployment scripts that use a combination of dacpacs through sqlpackage and straight scripts using sqlcmd.
When I execute the sqlpackage dac\sqlpackage.exe /p:BlockOnPossibleDataLoss=False /p:BackupDatabaseBeforeChanges=True /a:Publish /sf:.\somedeploy.dacpac /tcs:"Data Source=MyDB;Initial Catalog=MyCatalog;Trusted_Connection=True;"
I get an error message *** Could not deploy package. Unable to connect to target server. I have login auditing turned on in sql and the message I am getting is Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 111.222.223.224]
However, I can run our sql scripts through sqlcmd no problem by using the -E argument.
sqlcmd -i Permissions\CreateSqlUser.sql -S MyDB -E
I am running from a commandline that is set to "Run As Administrator" and am currently signed in as the admin. This is running on a Windows Server 2012 VM. I am using sql 2014. We have other installs that haven't had problems but this is our first 2014 install so we are trying to determine if something changed or if we are missing something and if so what.
If I run from profiler I don't see any audit log error messages. I checked the filters and what events I'm listening for and they all look good. Inside sql when I run exec sys.sp_readerrorlog 0, 1, 'Login Failed' I do get the messgaes to show up. (I might be doign something wrong in profiler). Also they show up in the system event logs. I'm not seeing anyplace where it tells me anything about the user attempting to login though.
If don't use trusted connection for sqlpackage and instead use a username and password it works fine. However, part of what our deployment script does is create the users so our preference would be to not do this.
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 have two SQL Servers which have been linked using sp_addlinkedserver 'ServerB\Instance' from ServerA and sp_addlinkedserver 'ServerA\Instance' from ServerB.
If I execute the following query from ServerA then everything is okay:
SELECT *
FROM [ServerB\Instance].Database.dbo.Table
If I execute the following query from ServerB an error occurs:
SELECT *
FROM [ServerA\Instance].Database.dbo.Table
Error:
Msg 18456, Level 14, State 1, Line 1
Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
The service accounts that SQL Server runs under on ServerA and ServerB have been given elevated permissions on both servers in an attempt to solve the issue but no success.
I have done research but want to avoid a convoluted process when communication one way is okay.
I have solved this by following the process:
Deleted both linked servers.
Executed sp_addlinkedserver for ServerA from ServerA RDP (SSMS) and for ServerB from ServerB RDP (SSMS).
Previously I had executed sp_addlinkedserver for both servers from the one server RDP (SSMS) session only. Executing from each server has solved the problem. If someone can add comments as to why this is then I will be very grateful.
In SQL Management Studio, view the properties for the linked server from Server B to Server A. There's a security "tab" that you can view from there. That will tell you the security context the connection from B to A is using. The error you are getting normally occurs when you don't have a valid security context set for the linked server.
The reason that it can work from A to B and not B to A is that you need to set up the linked server correctly on each side. Just doing it for one is not going to work to go both ways.
You have to map your local user to a remote user on the other server.
Do can do this by calling sp_addremotelogin() as explained here: http://msdn.microsoft.com/en-us/library/ms186338.aspx
To work around this problem, use one of the following methods:
Map the clients on server A to a standard security login on server B, by using either the sp_addlinkedsrvlogin stored procedure or the Security tab of the Linked Server Properties dialog box in Enterprise Manager.
If you are running the distributed query on an instance of SQL Server that is running on a Microsoft Windows 2000-based computer, configure SQL Server to listen for client requests by using the Named Pipes Server network library, instead of using the TCP/IP Server network library or the Multiprotocol Server network library. To configure the Server network libraries for SQL Server, use the Server Network Utility.
Take a look at:
http://support.microsoft.com/kb/238477
This wiki post outlines both a problem and a solution. I wanted to post this for others that may be having similar problems, as I couldn't find anything specifically to solve this problem elsewhere.
We recently upgraded our SQL Server 2000 database to SQL Server 2005. One of the databases on the server is a back-end to a MS Access database. The MS Access database uses pass-through queries, via DSN-less ODBC to connect to SQL Server.
An example of the DSN-less connection string is shown below:
ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
Trusted_Connection=Yes
After the upgrade, we found that users were unable to run the pass-through queries, and were getting the following error displayed :
ODBC -- connection to 'SQL Server
' failed
This initially appeared to be a permission issue, as elevating the priveledges of the SQL server logins to sysadmin server role alleviated the problem (but obviously this isn't a great solution).
After taking the logins back out of the sysadmin role we found that when connecting to SQL Server via Management Studio, the login could execute the stored procedures. The very same login could not from within MS Access. This pointed to something MS Access was doing while trying to execute the stored procedures - rather than a permission issue.
We ran a trace on the server using Profiler, and this showed up MS Access trying to execute the following command prior to stored proc execution:
DBCC TRACEON(208)
It appeared to fail at this command, prior to stored procedure execution. Research on the web showed that DBCC TRACEON(208) is equivalent to using 'SET QUOTED IDENTIFIERS ON' command, and that in SQL 2005 priveledges to run this DBCC command had been revoked.
After further research, we found references to MS Query having a similar problem, and that the APP component of the connection string should be changed from 'MS Query' to something else.
On a hunch, we changed our APP component of the ODBC connection string, and MS Access no longer tried executing DBCC TRACEON(208) prior to stored procedure execution.
After further testing, we tracked the problem down to the 'copyright' symbol included in the APP component :
APP=Microsoft® Access (Pass Through Query)
By removing the copyright symbol, all was well with the connection and the application worked as it had previously done on SQL 2000.
Hope this helps out anyone else having a similar problem.
Isn't that the registered trademark symbol?
I believe you hit on one of sql server 2005's defences against odbc based attacks. Since there isn't anything on the internet about it, it is likely something MS handled internally.
I've just installed SQL Server 2008 Developer edition and I'm trying to connect using SQLCMD.exe, but I get the following error:
H:\>sqlcmd.exe -S ".\SQL2008"
Msg 18452, Level 14, State 1, Server DEVBOX\SQL2008, Line 1
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
The SQL Server instance is configured to use SQL Server and Windows Authentication mode. If I specify -U sa then I can log in successfully, but I'd like to use windows authentication. Connecting using SSMS with windows authentication seems to work fine.
I had this issue and it was because the machine running the application isnt trusted for delegation on the domain by active directory. If it is a .net app running under an application pool identity DOMAIN_application.environment for example.. the identity can't make calls out to SQL unless the machine is trusted.
You're not passing any credentials to sqlcmd.exe
So it's trying to authenticate you using the Windows Login credentials, but you mustn't have your SQL Server setup to accept those credentials...
When you were installing it, you would have had to supply a Server Admin password (for the sa account)
Try...
sqlcmd.exe -U sa -P YOUR_PASSWORD -S ".\SQL2008"
for reference,
theres more details here...
In my case, this error was caused by renaming my client machine. I used a new name longer than 13 characters (despite the warning), which resulted in the NETBIOS name being truncated and being different from the full machine name. Once I re-renamed the client to a shorter name, the error went away.
Just tried this:
H:>"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe" -S ".\SQL2008"
1>
and it works.. (I have the Microsoft SQL Server\100\Tools\Binn directory in my path).
Still not sure why the SQL Server 2008 version of SQLCMD doesn't work though..
Your error is quite literally saying "you're trying to use Windows Authentication, but your login isn't from a trusted domain". Which is odd, because you're connecting to the local machine.
Perhaps you're logged into Windows using a local account rather than a domain account? Ensure that you're logging in with a domain account that is also a SQL Server principal on your SQL2008 instance.
Do you specify a user name and password to log on? What exactly is your complete command line?
If you're running on your own box, you can either specify a username/password, or use the -E parameter to log on with your Windows credentials (if those are permitted in your SQL server installation).
Marc
I was getting this error too, although my issue was that I kept switching between two corporate networks via my Virtual Machine, with different access credentials. I had to run the command prompt:
ipconfig /renew
After this my network issues were resolved and I could connect once again to SQL.
Just found this thread and posted an alternative answer (copied below) here:
https://stackoverflow.com/a/37853766/1948625
Specifically on this question, if the dot "." used in the -S value of the command line means the same as 127.0.0.1, then it could be the same issue as the connection string of the other question. Use the hostname instead, or check your hosts file.
Old question, and my symptoms are slightly different, but same error. My connection string was correct (Integrated security, and I don't provide user and pwd) with data source set to 127.0.0.1. It worked fine for years.
But recently I added a line in the static host file for testing purposes (C:\Windows\System32\drivers\etc\hosts)
127.0.0.1 www.blablatestsite.com
Removing this line and the error is gone.
I got a clue from this article (https://support.microsoft.com/en-gb/kb/896861) which talks about hostnames and loopback.
Other possible fix (if you need to keep that line in the hosts file) is to use the hostname (like MYSERVER01) instead of 127.0.0.1 in the data source of the connection string.