SQL Server 'Cannot create an instance of OLE DB provider "SQLNCLI11" for linked server' after patching - sql-server

One of our servers went for a reboot last night after doing OS and SQL Server patching (SQL Server 2016 latest CU). Since then any call to a linked server from the patched server fails with the above error.
Other servers can still connect to the patched server, just outbound doesn't seem to work at all.
We also have an issue with the SQL Server Browser service wont start "stopped unexpectedly", although not sure if its related
Any help greatly appreciated

Microsoft OLEDB Providers - part of the SQL Server Native Client (SNAC) are deprecated:
SQLNCLI10
SQLNCLI11
You need to install Microsoft OLE DB Driver for SQL Server:
MSOLEDBSQL
The switch happened in 2018. You can read about it here:
Announcing the new release of OLE DB Driver for SQL Server
Released: Microsoft OLE DB Driver for SQL Server

Ok people, problem solved.
One of the updates tried to upgrade the OLEDB connectors, ran into a problem and bailed. It had already deleted the DLLs for the drivers though.
Finding the drivers on the Dev server and copying them across solved the issue.
For those bleeding on about SNAC on being on SQL12, that was it's release version. It's been a staple ever since and is installed as standard by SQL16. It's not untill 2022 that it's replaced

Related

SQL Server 2019 cannot see Oracle 12.2.0 OraOLEDB12.dll in Providers list

My SQL Server 2019 Enterprise is up and running on a Windows 2019 Core vm. Connections to SQL Server databases are A-OK.
I have installed the OLEDB driver OraOLEDB12.dll via the oui.exe in the ODTwithODAC122011.zip.
I checked only the Oracle Provider for OLE DB in the Component Name list.
It created the appropriate TNSNAMES.ORA file from the info I provided.
The installer added the appropriate paths to the environment var PATH.
After restarting the Windows 2019 Core VM, and reconnecting SSMS v18.8 to the SQL Server I could not see the provider in the Server Objects, Linked Servers, Providers list.
So I ran regsvr32.exe and got back DllRegisterServer in OraOLEDB12.dll succeeded. So I restarted the VM again, and reconnected to my SQL Server and still no joy.
What am I missing here? I've search through lots of google links, on StackOverflow itself and am finding the same results, path issues, registry issues, 32/64 issues. Our Ent SQL Server is x64, our SSMS locally is X64, the Oracle driver is x64.
Did you try to install more than one Oracle client? Oracle OLEDB driver can exist only once (i.e. once each for 32-bit and 64-bit).
Version of Oracle OLEDB driver must match exactly the Oracle client.
Maybe have a look at my Oracle Connection Tester, this may give you an indication whether your Oracle OLEDB driver is properly installed.
Gentlepersons,
My apologies, I did indeed install the 32 bit driver when I thought I was installing the 64 bit.
Have deinstalled (as Oracle calls it) the previous and am moving forward with the correct installation.
Again, my apologies for wasting time.
G

SQL OLEDB fails with TLS 1.2

I know this is a very generic question, and already answered in some forums but I am having issue. I am having SQL Server 2012 and 2015 (which would be migrated to 2018). The SQL OLEDB connection with SqlClient works well with TLS 1.1 or TLS 1.0. But when we use TLS 1.2, it fails to connect.
I have gone through this and this link, explaining the same, but any more changes I need to make in my application, regarding Provider etc.
Thanks In Advance!!!..
You should Use "SQLNCLI11" driver to connect to the database or you can install new OLEDB provider from here :
https://www.microsoft.com/en-us/download/details.aspx?id=56730
and set provider to "MSOLEDBSQL"

SQL Server 64-bit ODBC Connection to 32-bit Pervasive SQL v10

I am using the 64-bit version of SQL Server 2016 Express, trying to connect to a 32-bit Pervasive SQL v10 database. I am setting up a Linked Server in SQL Server via ODBC connection, but I am receiving this error that has given me a lot of pain in the past:
The specified DSN contains an architecture mismatch between the Driver and Application
I had a similar issue not long ago trying to connect to a Microsoft Access database, but with help here I was able to obtain the 64-bit ODBC driver for Access. However, there does not seem to be one for Pervasive v10 at all, only for PSQL v11+, which does not help me in this case.
Previous question: SQL Server Linked Server to MS Access - DSN Architecture Mismatch Error
So if anyone has a suggestion for connecting to a 32-bit client from a 64-bit SQL Server installation, when there does not exist a 64-bit ODBC driver for this client, please let me know.
One of the suggested solutions was to use an OLEDB link instead (but no details provided on this, and I'm not sure how it would differ from the linked server I am already trying to create, which is already using OLEDB).
There was also mention somewhere of installing an entirely separate 32-bit SQL Express client, and chaining an additional ODBC link to point to the first one, but I would rather avoid all that overhead if possible, especially since this is a production server that is already running Sage 50 in addition to our own software and web services with SQL Server...
Other details: The client that is built on Pervasive SQL v10 that I am trying to connect to is Peachtree 2017 - Sage 50. This is all running on Windows Server 2012 R2 Standard.
More reading here:
https://support.na.sage.com/selfservice/viewdocument.do?noCount=true&externalId=12693&sliceId=1&cmd=displayKC&dialogID=50216&docType=kc&noCount=true&isLoadPublishedVer=&stateId=50217&docTypeID=DT_Article&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl
https://www.experts-exchange.com/questions/23995371/Installing-Pervasive-SQL-Client-on-Windows-2008-64bit-missing-ODBC-Driver.html
Edit:
Thanks for the comments! After further investigation... it looks like this IS actually PSQL v11, not v10. Now, I'm not sure why the 64-bit ODBC driver is not already installed... but I am looking into this now...

Does Microsoft OLE DB Provider for SQL Server support TLS 1.2

Our client recently upgraded from TLS 1.0 to TLS 1.2 and after this our software cannot connect with SQL server. It uses OLE DB provider for connecting to SQL server.
Below is the error which is returned from SQL server-
[DBNETLIB][ConnectionOpen SECDoClientHandshake()]SSL Security error
SQL State: 08001
SQL Error Number: 18
Could not find any useful information related to whether Microsoft OLE DB Provider for SQL Server support TLS 1.2 or not.
One of the links I found seems to suggest that it is not supported.
https://forums.iis.net/t/1233674.aspx?connecing+SQL+server+DB+issue+after+installingTLS1+2+in+SQL+srver+with+classic+asp+application+
Hence, wanted to check on stackoverflow in case anyone has any information on this.
The SQLOLEDB provider and the SQL Server ODBC driver that ship with Windows are legacy components provided only for backwards compatibility. These have been deprecated since SQL 2005.
According to this blog post by the MSSQL Tiger Team:
SQLOLEDB will not receive support for TLS 1.2. You will need to switch
your driver to one of the supported drivers listed in
https://support.microsoft.com/en-us/kb/3135244
You should be able to install SQL Server Native Client 2012 and use that OLE DB provider with only a connection string change (change Provider=SQLOLEDB to Provider=SQLNCLI11). Of course, once should test to avoid surprises. For example, I recall someone experiencing behavior differences with the SQL Server Native Client provider and ADO classic when server API cursors were used, although the commonly used firehose cursors were fine. 
EDIT
The new OLE DB driver, MSOLEDBSQL, has been released. This new driver includes the support for the latest TLS 1.2 standards and is backwards compatible with SQL Server Native Client 11 (SQLNCLI11). See the Microsoft SQLNCLi team blog announcement. Change the connection string to Provider=MSOLEDBSQL after installation.
EDIT #2
Time continues to march on. The SQL Server Native Client OLE DB driver is now deprecated in favor of MSOLEDBSQL. End of support for the final 2012 SNAC version is July 12, 2012.
Furthermore, as David called out in his answer, Microsoft recently added support for TLS 1.2 MDAC components in Windows 10 Build 17763.1554:
Adds support for the Transport Layer Security (TLS) 1.1 and 1.2
protocols when connecting to SQL Server using the data providers in
Microsoft Data Access Components (MDAC)
No enhancements (e.g. support for post-SQL 2000 data types) were added, though.
In summary, newer SQL Server client drivers provides more control over the specific driver and version without a direct OS patch level dependency. Modern drivers like MSOLEDBSQL and ODBC Driver n for SQL Server are continuously improved to support latest SQL Server features and security standards.
EDIT#3
SQLOLEDB and the SQL Server ODBC driver (part of MDAC, shipped and serviced with Windows) has support for TLS 1.2 with October 20, 2020 build, version 17763.1554. This applies to Windows 10 and Windows Server 2019 or later.
This may not be a solution for you, since it's a future fix your client may not be able to wait for, but apparently Microsoft is undeprecating the OLEDB Driver, with a new release supporting TLS 1.2 out Q1 2018: https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/
The new Microsoft OLE DB Driver for SQL Server, or msoledbsql, will
also introduce multi-subnet failover capabilities in this first
upcoming release, and keeps up with latest TLS 1.2 standards.
Also, this first upcoming release will be a stand-alone install
package that is out-of-band with SQL Server lifecycle. This also means
the driver will not be packaged in the SNAC library, nor coupled with
any other driver.
TLS 1.2 Support has been added to sqloledb in Windows. See KB4580390.
This includes support both ODBC and OleDB providers in MDAC:
Adds support for the Transport Layer Security (TLS) 1.1 and 1.2
protocols when connecting to SQL Server using the data providers in
Microsoft Data Access Components (MDAC)
You can verify that MDAC has been updated by checking the Windows build number, anything 17763.1554 or later has this fix. MDAC has not been distributed outside of OS patches for many years.
The build is visible in winver or in Powershell with [environment]::OSVersion.Version.Build
Following changes on my end fixed the issue after TLS1.2 upgrade on Azure cloud -
change Provider=SQLOLEDB to Provider=SQLNCLI11
update ADODB version to Microsoft ActiveX Data Objects 6.0 Library
The use of "Microsoft OLEDB Driver for SQL Server" is what worked for us but I can also confirm Native Driver 11 also tests OK.
Here was our scenario: after we disabled TLS 1.0 and 1.1 and enabled TLS 1.2, Crystal Reports using the "Microsoft OLEDB Provider for SQL Server" would no longer connect. Instead you get a user/pw prompt that fails with even with valid credentials. In our case we were running Crystal Reports from within an ASP.NET v4.5.2 application that has the Crystal 13 Viewer embedded in. Users pick from a list of reports and run them and they run without a prompt with TLS 1.0 enabled.
To fix this, we had to open the report in the designer and convert it report from using the "Microsoft OLEDB Provider for SQL Server" to using the "Microsoft OLEDB Driver for SQL Server".
If you don't see the driver in your list here's the OLEDB Driver for SQL Server: https://learn.microsoft.com/en-us/sql/connect/oledb/download-oledb-driver-for-sql-server?view=sql-server-ver15
Credit to Dan Guzman who mentioned the existence of the "driver" in a somewhat buried comment and an update above.
This might not directly answer the question, but it is still related to sql server connection with TLS 1.2 error.
I'm maintaining an old ASP Classic website which broke with following error.
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.
Changing Provider from SQLOLEDB to SQL Server Native Client 11.0 or any higher version which is available fixed the error.
Thus, changing connection string from
constr = "Provider=SQLOLEDB;Data Source=..."
to
constr = "Provider=SQL Server Native Client 11.0;Data Source=...."
might work too

Connecting to SQL Server using Delphi and dbExpress

I use RAD Studio 2010 including latest updates 4 and 5, my database is SQL Server Express.
I set up a TSQLConnection but it won't connect, error message is "DBX-Error: the driver could not be initialized correctly. A client library may be missing, may not be installed correctly, or may have the wrong version" (error messagetranslated from German).
Connecting to the database via TADOConnection works fine with both ADO drivers ("Microsoft OLE DB Provider for SQL Server" and "SQL Native Client").
Can anybody give me a hint how to connect via dbExpress?
you need to install the sql native client, if you read the read me that comes with RAD studio 2010 its says that it is a requirement for connecting to sql server 2000/2005/2008
I’ve also discovered that in dbxdrivers.ini they haven’t added the proper option for MSSQL 2000/2005 you need to edit the top bit to add in MSSQL9=1
example:
[Installed Drivers]
DBXTrace=1
DBXPool=1
BlackfishSQL=1
DataSnap=1
ASA=1
ASE=1
DB2=1
Firebird=1
Informix=1
Interbase=1
MSSQL=1
MSSQL9=1
MySQL=1
Oracle=1
you can then select MSSQL9 as a dbExpress option and it should also appear in data explorer as well
I had a similiar issue with Delphi XE2 ad SQL Server 2005. I uninstalled and installed several versions (including MSSQL 2008 R2) of SQL Native Client to no avail. But adding MSSQL9=1 to the ini file worked.
Maybe this thread on the EDN (Embarcadero Developer Network) can be helpful.

Resources