I have a SQL Server 2005. I am trying to create a linked server to Azure SQL.
I set it up and tested the connection says it succeeded. However running any queries against it yields this
Enumerate columns failed for LinkedServer 'EBPCLOUD'. (Microsoft.SqlServer.Smo)
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Cannot obtain the schema rowset "DBSCHEMA_COLUMNS" for OLE DB provider "SQL Server" for linked server "(null)". The provider supports the interface, but returns a failure code when it is used. (Microsoft SQL Server, Error: 7311)
The exact same queries work on a different box, albeit with a newer version of SQL Server.
SQL Server 2005 will not connect to Azure, 2008 R2 or higher required.
Related
The problem: I'm getting this error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server.
The server was not found or was not accessible.
Verify that the instance name is correct and that SQL Server is configured to allow remote connections.
(provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) (Microsoft SQL Server)
Program files shows this:
MSSQL13.SQLEXPRESS
MSSQL14.SQLEXPRESS
MSSQL14.SQLEXPRESS01
I can access MSSQL14.SQLEXPRESS01 from SSMS 17.9.1, but all of my databases are in MSSQL13.SQLEXPRESS.
Installation:
SQL Server Management Studio 17.9.1
Visual Studio 2019 16.2.1
How can I access the databases in MSSQL13.SQLEXPRESS?
Turns out that "for some reason" SQL Server Services for SQL Server express was not running.
After I used services.msc to start it, I was able to open the SQL Server 13 engine (SQL Server 2016) and see all of my "old" databases.
Thanks to Vivek Janakiraman for providing a solution on the MSDN SQL Server forum.
When I create a linked server in SQL Server, it causes an error
Cannot create a instance of OLEDB provider SQLNCLI10 for linked server 'linked server name '(microsoft sql server error 7302)
How can I rectify this error?
The OLEDB provider may not properly installed. What you chose is the SQL Server native client. Do you have SSMS installed on server? This should come with sql native client OLE DB.
I would like to share an experience when I faced following error
Cannot create an instance of OLE DB provider "xxx.YYYY" for linked server "test". Error 7302.
I observed this message from a failed SQL Server job. On analysis it is found that Allow Inprocess was not enabled for the provider. When this is enabled, everything worked fine for me.
Server Objects --> Linked Servers --> Providers
Also refer following
"Cannot create an instance of OLE DB provider" error as Windows Authentication user
Linked Server Properties (Provider Options Page)
Configuring OLE DB Providers for Distributed Queries
I have a SSIS package that runs on a SQL Server 2005 instance that currently migrates data from one SQL Server 2000 database on another server to a SQL Server 2005 database on the server running the SSIS package. The database on SQL Server 2003 is migrating to SQL Server 2008 R2. When I try to run the current SSIS package on the SQL Server 2005 database (after changing the connection strings), I receive the following error:
Error: 2011-10-20 15:09:45.85 Code: 0xC0202009 Source: SSIS_Job Connection manager "2008R2Conn" Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040154. An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered". End Error Error: 2011-10-20 15:09:45.85 Code: 0xC020801C Source: Step [121] Description: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "2008R2Conn" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed. End Error Error: 2011-10-20 15:. The step failed.,00:00:17,0,0,,,,0
I changed the connection string from:
<Configuration ConfiguredType="Property" Path="\Package.Connections[2008R2Conn].Properties[ConnectionString]" ValueType="String">
<ConfiguredValue>Data Source=TargetDB;User ID=;Initial Catalog=TargetCatalog;Provider=SQLNCLI.1;Integrated Security=SSPI;Auto Translate=False;</ConfiguredValue>
</Configuration>
to:
<Configuration ConfiguredType="Property" Path="\Package.Connections[2008R2Conn].Properties[ConnectionString]" ValueType="String">
<ConfiguredValue>Data Source=TagetDB\Instance,<Port #>;User ID=;Initial Catalog=TargetCatalog;Provider=SQLNCLI10.1;Integrated Security=SSPI;Auto Translate=False;</ConfiguredValue>
</Configuration>
I know I had to change the SQL Server Native Client provider b/c the original one is not included in SQL Server 2008 R2.
I set up a test instance of SQL Server 2008 R2 and ran the package from there and it worked successfully, but my client doesn't want to run the SSIS package from one of the servers with SQL Server 2008 R2 on it, so I'm stuck trying to get the SQL Server 2005 SSIS package to call the SQL Server 2008 DB. Any suggestions?
I know I had to change the SQL Server Native Client provider b/c the original one is not included in SQL Server 2008 R2.
You only need to change the SQL Native Client provider if you're going to run the package on a SQL Server 2008 box, because the SQLNCLI.1 provider doesn't ship with SQL Server 2008. (We're in the middle of a 2005->2008R2 upgrade and got bit by this.)
However, the SQLNCLI.1 provider is perfectly capable of communicating with SQL Server 2008 R2, so you should be able to run the package on your SQL Server 2005 box and have it update the data on the SQL Server 2008R2 database. (I just tried it on a Windows 2003 server running SQL Server 2005 and it worked fine.)
I am facing a strange problem during data migration. We "restored" data from 3 shards(on diff SQL Server 2005 machines) to single SQL Server 2008. We have single 2008 server now but the shards are unchanged from 2005.
Now I am trying to exec a SP on Master but I get the following error
Creating SP
OLE DB provider "SQLNCLI10" for linked server "(null)" returned message "Login timeout expired".
OLE DB provider "SQLNCLI10" for linked server "(null)" returned message "A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.".
Msg 53, Level 16, State 1, Line 0
Named Pipes Provider: Could not open a connection to SQL Server [53].
All shards are on SQL Server. We are not using SQLNCLI10 provider. But it's strange to see this error.
My SP use some dynamically created distributed queries in SP.
eg. Shard01.dbo.Update.....
What could possible go wrong.
Solved the problem.
My SP was using a view which was moved restored from 2005 to 2008. 2008 has different shards configurations and SQLNCLI10 was used for OPENROWSET in 2005 but not in 2008 as all the DBs were on same server.
Redefining the view solved the issue.
Does a linked server connection on SQL Server 2008 get shared between connections to the SQL Server? I am wondering this because I have a SQL Server 2008 with a linked Sybase server. If I open up Management Studio and connect to the SQL Server and execute the following
exec('select id into #tempTable from test') AT LINKEDSERVER
And then open up another window in Management Studio and execute the statement again I get a table already exists. The same things also seems to be happening if I execute it through code and then try it through Management Studio.
Is the linked server connection being shared between different connections to the SQL Server or is something else going on?
I confess my experience with Sybase is pretty limited, but does it use the OLE DB provider for the linked server? If so, yes you should be getting connection pooling as OLE DB provides connection pooling.
It appears that this was a connection pooling issue. It wasn't that the connection between the linked server and SQL Server was getting reused, it was that the connections to the SQL Server were getting reused because of connection pooling.