I would like to make a copy of what's on my remote server at xxx.safesecureweb.com.
How do I connect to it from my local SQL Server?
Is the syntax something like:
sp_addlinkedserver
#server='PRODUCTION',
#provider='xxx.safesecureweb.com',
#Username='myUsername',
#Password='myPassword'
What I'm thinking of doing is writing a bunch of insert statements like:
INSERT INTO Test.Table
SELECT * FROM Production.Table
You do not specify the remote user and password in the linked server definition. Linked servers have a separate object that mapps the login of users connected to the local server (the 'locallogin') with remote logins. See Security for Linked Servers. For example, the following maps all local logins on the linked server to the specified MyUserName SQL Login:
exec sp_addlinkedserver 'xxx.safesecureweb.com';
exec sp_addlinkedsrvlogin 'xxx.safesecureweb.com'
, 'FALSE', NULL, 'myUserName', 'myPassword';
You can only map with user/password a remote SQL login. Remote Windows logins (trusted authentication) must use integrated authentication and configure the server for constrained delegation.
Provider should be the client provider you want to use to connect. #datasrc is the servername to connect to.
sp_addlinkedserver
#server='PRODUCTION',
#provider='SQLNCLI', -- sql native client.
#Username='myUsername',
#Password='myPassword',
#dataSrc = 'xxx.safesecureweb.com'
Then, when querying, I believe you need to use a four part name fot the table:
INSERT INTO Test.Table
SELECT * FROM Production.mydatabase.dbo.Table
http://msdn.microsoft.com/en-us/library/ms190479.aspx
Related
I am trying to configure the distribution of SQL Server (2016). This is an Azure SQL VM. However, when doing so I get the following error:
TITLE: Configure Distribution Wizard
------------------------------
SQL Server is unable to connect to server 'COMPANY-SQL'.
SQL Server replication requires the actual server name to make a connection to the server. Specify the actual server name, ''. (Replication.Utilities)
(note it is not actually COMPANY-SQL but a similar naming format). I have tried, as suggested in many posts to sp_dropserver and sp_addserver. This successfully creates ##SERVERNAME set to company-sql-2 which is the name of both my Azure resource (not sure where COMPANY-SQL originates). I'm lost as to how to connect here despite already being connected to the database & why the error says the actual server name is simply ''.
SQL Server is unable to connect to server 'COMPANY-SQL'.
SQL Server replication requires the actual server name to make a connection to the server. Specify the actual server name, ''. (Replication.Utilities)
SERVERPROPERTY: The Windows server and instance name, which together make up the specific server instance, are provided by the ServerName attribute.
##SERVERNAME: The name of the local server as it is set up right now is provided by ##SERVERNAME.
Run the following commands together and you will get two different names.
SELECT SERVERPROPERTY(N'servername')
SELECT ##SERVERNAME
then change the server name by dropping the name got by ##SERVERNAME command with sp_dropserver procedure and set name got by SERVERPROPERTY command with sp_addserver procedure then Restart the SQL Server Service.
I followed all the instructions I could find:
Installed latest Snowflake 64bit ODBC driver to my SQL Server VM
Created system dsn for it (filled in User, Server, Database, Schema, Warehouse, Role and Tracing fields)
In SQL server, for the MSDASQL linked server provider, enabled following parameters: Nested queries, Level zero only, Allow inprocess, Supports 'Like' Operator
Created linked server following instructions
Provider=Microsoft OLE DB Provider for ODBC drivers
Data source: name of system DSN I created
Security:
mapped local login 'NT AUTHORITY\SYSTEM' to remote username and password (they work when I connect to Snowflake via web browser)
click 'Be made using the login's current security context'
when clicking ok, I get the following error
In the security tab of the linked server:
you have mapped 'NT AUTHORITY\SYSTEM' (is this the sql service account?) to remote username and password.
For any other login not in the list you have selected Be made using the login's current security context
You connect to sql server using a windows login or a sql server login. Assume you either use domainxyz\rick or username: sqlrick and password: rick1212.
When you try to use the linked server, both possible logins (domainxyz/rick or sqlrick) are not mapped to a remote[snowflake] username and password. So sql server passes through the current security context which is either your domainxyz/rick token or the sqlrick username&password. Both do fail for an external server(can they even work?).
From https://learn.microsoft.com/en-us/sql/relational-databases/linked-servers/create-linked-servers-sql-server-database-engine
Be made using the login's current security context
Specify that a connection will be made using the current security context of the login for logins not defined in the list. If connected to the local server using Windows Authentication, your windows credentials will be used to connect to the remote server. If connected to the local server using SQL Server Authentication, login name and password will be used to connect to the remote server. In this case a login with the exact same name and password must exist on the remote server.
You could either map your login to the remote snowflake username&password, or choose
For a login not defined in the list above, connections will:
Be made using this security context and fill in the username&password for snowflake in the boxes.
/*
snowflake server=xyz12345.west-europe.azure.snowflakecomputing.com
snowflake user= testuser
snowflake password = Testuser1
*/
--system DSN for snowflake named SNOWFLAKEDSN [SnowflakeDSIIDriver, User: testuser, Server:xyz12345.west-europe.azure.snowflakecomputing.com, Database:DEMO_DB, Tracing:4 (default)]
--Note: Attempting any of the commands with a wrong password could lock temporarily the snowflake account. tread carefully
--snowflake without linked server
--openrowset using dsn
SELECT *
FROM OPENROWSET('MSDASQL', 'DSN=SNOWFLAKEDSN;UID=testuser;PWD=Testuser1', 'select cast(TABLE_NAME as varchar(100)) as tablename from demo_db.information_schema.tables');
--openrowset using dsn2 , format= provider, DSN;uid;password, query
SELECT *
FROM OPENROWSET('MSDASQL', 'SNOWFLAKEDSN';'testuser';'Testuser1', 'select cast(TABLE_NAME as varchar(100)) as tablename from demo_db.information_schema.tables');
--openrowset without dsn
SELECT *
FROM OPENROWSET('MSDASQL', 'DRIVER=SnowflakeDSIIDriver;SERVER=xyz12345.west-europe.azure.snowflakecomputing.com;UID=testuser;PWD=Testuser1', 'select cast(TABLE_NAME as varchar(100)) as tablename from demo_db.information_schema.tables');
GO
--linked server using DSN
EXEC master.dbo.sp_addlinkedserver #server = N'SNOWFLAKE_WITH_DSN', #srvproduct=N'', #provider=N'MSDASQL', #datasrc=N'SNOWFLAKEDSN';
/*every login of the sql instance connects to snowflake as testuser*/
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'SNOWFLAKE_WITH_DSN',#useself=N'False',#locallogin=NULL,#rmtuser=N'testuser',#rmtpassword='Testuser1';
--linked server without DSN, name of linked server is SNOWFLAKE_WITHOUT_DSN
EXEC master.dbo.sp_addlinkedserver #server = N'SNOWFLAKE_WITHOUT_DSN', #srvproduct=N'', #provider=N'MSDASQL', #provstr=N'DRIVER=SnowflakeDSIIDriver;SERVER=xyz12345.west-europe.azure.snowflakecomputing.com';
/*every login of the sql instance connects to snowflake as testuser*/
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'SNOWFLAKE_WITHOUT_DSN',#useself=N'False',#locallogin=NULL,#rmtuser=N'testuser',#rmtpassword='Testuser1';
--linked server without DSN, hardcoded snowflake creds in the provider string (at own risk)
/*
EXEC master.dbo.sp_addlinkedserver #server = N'SNOWFLAKE_WITHOUT_DSN_HARDCODED_CREDS', #srvproduct=N'', #provider=N'MSDASQL', #provstr=N'DRIVER=SnowflakeDSIIDriver;SERVER=xyz12345.west-europe.azure.snowflakecomputing.com;UID=testuser;PWD=Testuser1';
/*creds hardcoded in the connection string, logins use their own security context */
/* caveat: this worked ok for windows authenticated logins. sql authenticated logins could not use the linked server, not tested with msdasql in process... */
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'SNOWFLAKE_WITHOUT_DSN_HARDCODED_CREDS',#useself=N'True',#locallogin=NULL,#rmtuser=NULL,#rmtpassword=NULL;
*/
I am trying to create a linked server in SQL Server:
--Create the link to server "uranium"
EXEC master.dbo.sp_addlinkedserver
#server = N'uranium',
#srvproduct=N'',
#provider=N'SQLNCLI'
--Add the catch-all login with SQL Server authentication
EXEC master.dbo.sp_addlinkedsrvlogin
#rmtsrvname=N'uranium',
#useself=N'False',
#locallogin=NULL,
#rmtuser=N'BatteryStaple',
#rmtpassword='Horsecorrect'
And it creates fine. But any attempt to query the linked server, e.g.:
SELECT * FROM uranium.Periodic.dbo.Users
results in
Msg 18456, Level 14, State 1, Line 1
Login failed for user 'BatteryStaple'.
Except i know the credentials are correct:
Login: BatteryStaple
Password: Horsecorrect
because i can login when i connect directly using SQL Server Management Studio, or any other technology that is able to connect to a database.
Bonus Reading
Login Failed for linked server (he forgot to call sp_addlinkedsrvlogin)
Why am I getting a “login failed” when creating this linked server? (he's trying to use integrated authentication)
MSDN Blogs: SQL Linked Server Query failed with “Login failed for user …” (he's trying to make integrated authentication work)
Note: New SQL Server 2014 install. Every existing SQL 2000, 2005, 2008, 2008 R2 can communicate to their uranium linked server. I'm certain it is related to Microsoft's frustrating broken by default policy.
The issue is that the SQL Server Management Studio interface creates the linked server using the OLEDB Provider:
This is equivalent to the original T-SQL:
--Create the link to server "uranium"
EXEC master.dbo.sp_addlinkedserver
#server = N'uranium',
#srvproduct=N'', #provider=N'SQLNCLI'
The fix is to create the linked server as SQL Server:
--Create the link to SQL Server "uranium"
EXEC master.dbo.sp_addlinkedserver
#server = N'uranium',
#srvproduct=N'SQL Server'
Shouldn't matter. Probably a regression in Microsoft SQL Server 2014 12.0.4213.0. Might be fixed in a service pack - if there is one.
But there it is; solved.
Old post, but might be useful still. In my case it was that only Windows Authentication was set. Setting authentication for both Windows and SQL Server on the linked server fixed it.
The issue for me was this: Since I was trying to connect to instance via servername\instancename - ALL my instances were running on port 1433 so the "Add Linked Server" was actually connecting to the default instance - and the login was failing.
Go to SQL Configuration Manager
Click on Protocols for [instancename]
Open TCP/IP properties and be sure it's enabled AND flip to the "IP Addresses" Tab and change the port on ALL IPs that you are using for your linked server IP is (a) active and (b) using a unique port - like 14333 (this was important as my VPN IP was not "active".
You may have to do this for both 32 and 64 if your machine is running both
DONT FORGET TO STOP and START THE INSTANCE
This is the fix
I have recently installed SQL Server 2014 Express and need to create a linked server. I have tried this in SQL Server Management Studio (from the object explorer - server objects - linked servers - add linked server).
When connecting to the server directly through Server type "SQL server" or by specifying the connection attributes in "Other data source" then Microsoft OLE DB Provider for SQL Server and filling in the additional details I receive the following error.
The linked server has been created but failed a connection test. SQL
Server native client 11.0 does not support connections to SQL Server
2000 or earlier versions.
I need to be able to create a joined query between two databases on different servers, what is the best way of achieving this ? The database I need to connect to is Version 8 (SQL Server 2000), very old. I have read it might be possible to achieve through transact SQL but not sure what steps to take.
It is possible to create a linked server but it cannot be done through the GUI. As a workaround you can create a DSN to use in transact SQL to link the servers.
For full instructions visit http://sqlwithmanoj.com/2012/12/10/sql-server-2012-does-not-support-linked-server-to-sql-server-2000-workaround/
=> WORKAROUND / FIX:
Now as a workaround to make this Linked Server work we have an option to use the ODBC Data Source which will connect to our remote server.
There are 2 approaches:
1. Either we create an ODBC Data Source (DSN) and use it in our Linked Server
2. Or, use the Data Source (DSN) connection string directly in the Linker Server Provider
–> Using appraoch #1:
Create an ODBC Data Source:
– Open Control Panel, go to Administrative Tools, then “Data Sources (ODBC)”.
– On “ODBC Data Source Administrator” window go to “System DSN” Tab.
– Here click on Add to create a new DSN.
– Choose “SQL Server” and click Finish.
– On the new window, give a proper name for the Source DSN (like: NorthWind2000DSN), we will use this name while creating our Linked Server. Provide the Server name which is on SQL Server 2000, here “NorthWind”. Click Next.
– Choose the Authentication Type, either Windows or SQL Server auth. Click Next.
– Change the default database, not necessary. Click Next.
– Click Finish. You will see a new DSN created under System DSN tab.
Now, create Linked Server and provide this DSN in the #datasrc param and provide the #provider param “MSDASQL”.
You can use the below query to create the same:
USE master
GO
-- Drop Existing LinkedServer [NorthWind2000]:
EXEC sp_dropserver #server=N'NorthWind2000', #droplogins='droplogins'
GO
-- Re-create LinkedServer [NorthWind2000] by using the ODBC connection:
EXEC sp_addlinkedserver #server = N'NorthWind2000',
#srvproduct=N'MSDASQL',
#provider=N'MSDASQL',
#datasrc = N'NorthWind2000DSN',
#location=N'System';
EXEC sp_addlinkedsrvlogin #rmtsrvname=N'NorthWind2000',
#useself=N'True',
#locallogin=NULL,
#rmtuser=NULL,
#rmtpassword=NULL
GO
–> Using appraoch #2:
We can also directly put the DSN connection String in the Provider String #provstr param.
Let’s check it below:
USE master
GO
-- Drop Existing LinkedServer [NorthWind2000]:
EXEC sp_dropserver #server=N'NorthWind2000', #droplogins='droplogins'
GO
-- Re-create LinkedServer [NorthWind2000] by using the ODBC connection:
EXEC sp_addlinkedserver #server = N'NorthWind2000',
#srvproduct=N'',
#provider=N'MSDASQL',
#provstr=N'DRIVER={SQLServer};SERVER=NorthWind;Trusted_Connection=yes;'
EXEC sp_addlinkedsrvlogin #rmtsrvname=N'NorthWind2000',
#useself=N'True',
#locallogin=NULL,
#rmtuser=NULL,
#rmtpassword=NULL
GO
I have a SQL Server 2012 Express installation with a new DB called BRD that I have created. I have also created a test table (tempDemo), and a test stored procedure (getStList) in the BRD database. The stored procedure works when I run it in the query window so I believe the table and stored procedure are legit. The SQL Server is set to "SQL Server and Windows Authentication mode".
I then attempted to create a Classic ASP page that then connected to the SQL Server using the following connection string:
objConn.ConnectionString="Provider=SQLOLEDB;Server=XPSI7\SQLEXPRESS;Database=BRD;Integrated Security=SSPI;"
This fails with the following message:
"Microsoft OLE DB Provider for SQL Server error '80004005'
Cannot open database "BRD" requested by the login. The login failed."
When I change the database to MASTER instead of BRD the ASP page does not error out. I'm just testing the connection string by opening it and then closing it, but it appears to work.
I've looked at the security settings for MASTER and BRD in the Object Explorer, but have failed to notice a difference. I've also looked at the IIS_IUSRS for the folders, but no difference either - not sure if this is necessary anyway.
SQL Server authenticates your login at the server level. Then it tries to open the database you've asked to connect to. At this point, you need to either map a database-level user to the server-level login, or use a server-level login that inherently has sufficient privileges to use the database.
A simple (but not secure) way to demonstrate this using SQL Server Authentication:
USE master;
GO
CREATE LOGIN foo
WITH PASSWORD = 'bar', CHECK_POLICY = OFF;
GO
USE BRD;
GO
CREATE USER foo FROM LOGIN foo;
GO
EXEC sp_addrolemember N'db_owner', N'foo';
GO
Now in your ASP connection string, use:
objConn.ConnectionString = "Provider=SQLNCLI;Data Source=XPSI7\SQLEXPRESS;Initial Catalog=BRD;User ID=foo;Password=bar;"
You can also map whatever login you're using to a database user simply doing:
USE BRD;
GO
CREATE USER [YourDomain\IIS_IUSRwhatever]
FROM LOGIN [YourDomain\IIS_IUSRwhatever];
GO
That will grant them access to the database, but it will be up to you to decide what permissions to grant. This assumes that you are allowing anonymous access to the web server; if IIS is challenging and accepting Windows authentication, you'll need to do the above for the user(s) that will be submitting their credentials. In either case you should be able to continue using the connection string you have now.
Try the following connection string:
strConnection = "Provider=SQLNCLI10;Server=server_name;Database=" & BD_REMOTE_INITIAL_CATALOG & ";Uid=" & BD_REMOTE_USER_ID & "; Pwd=*****;"