Announcing the new release of OLE DB Driver for SQL Server


NOTE: the new release announcement is available here.

Previously, Microsoft announced deprecation of the Microsoft OLE DB Provider for SQL Server, part of the SQL Server Native Client (SNAC). At the time, this decision was made to try to provide more simplicity for the developer story around Windows native software development as we moved into the cloud era with Azure SQL Database, and to try to leverage the similarities of JDBC and ODBC for developers. However, during subsequent reviews it was determined that deprecation was a mistake because substantial scenarios within SQL Server still depend on OLE DB and changing those would break some existing customer scenarios.

With this in mind, we have decided to undeprecate OLE DB data access technology, and release a new version by the first quarter of calendar year 2018 March 2018. This new Microsoft OLE DB Driver for SQL Server will support connectivity to SQL Server (versions 2012 to 2017), Azure SQL Database and Azure SQL Data Warehouse from applications with the existing feature set of SQL Server Native Client 11. Following releases will incrementally provide updated functionality that was introduced to other drivers since SQL Server 2012, while maintaining backwards compatibility.

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.

Additional updates will be provided closer to a release date. In the meantime, learn about the current OLE DB Supportability Guidelines for existing applications, and refer to SNAC lifecycle explained for lifecycle clarifications on SNAC.

Note (2/6/2018): As stated above, the new OLE DB driver is msoledbsql. To use the new driver in existing applications, you should plan to convert your connection strings from sqlncli<x> or sqloledb, to msoledbsql. Also, keep in mind SNAC and MDAC/WDAC OLE DB continues to be deprecated, as detailed here.

For example, for a trusted connection using SQL Native Client (SNAC11), plan to convert from:

Provider=SQLNCLI11; Server=myServerName\theInstanceName;Database=myDataBase;
Trusted_Connection=yes;

 

to:

Provider=MSOLEDBSQL; Server=myServerName\theInstanceName; Database=myDataBase;
Trusted_Connection=yes;

 

For a trusted connection using the Microsoft OLE DB Provider for SQL Server, plan to convert from:

Provider=sqloledb; Data Source=myServerName\theInstanceName;
Initial Catalog=myDataBase; Integrated Security=SSPI;

 

to:

Provider=MSOLEDBSQL; Server=myServerName\theInstanceName; Database=myDataBase;
Trusted_Connection=yes;

 

Pedro Lopes (@sqlpto) – Senior Program Manager

Comments (7)

Cancel reply

  1. Mark Donoghue says:

    Can you confirm if Always Encrypted support will be added to the new OLEDB Driver? I realize this was introduced with SQL Server 2016 (and ODBC Driver 13) so it probably isn’t part of the existing feature set of Sql Server Native Client 11, but I’m really hopeful as this would allow us to use the functionality in our roadmap without switching to ODBC.

    1. For the 1st release we’ll only support multi-subnet and what SNAC 11 provided. So, the new release of OLE DB will not support Transparent Network IP Resolution, Always Encrypted, Azure AD Authentication, Bulk Copy and Table Value Parameters to begin with. We’re collecting feedback/scenarios on what to ad next based on customer priority, and I’d like to get your detailed feedback please.

      1. Mark Donoghue says:

        Is Bulk Copy changing or will it be removed and then added back later, I thought this already existed in the OLEDB Driver (we are using a bulk copy/BCP at present)?
        Our biggest priority would be Always Encrypted – the only other way to achieve this is to move all out code to ODBC which is not our preferred approach.

  2. AccessKungFu says:

    This is HUGE news for the Microsoft Access community! We were at our wits trying to figure out how to replicate OLE DB functionality with DAO and coming up short. Now we don’t have to worry about re-writing a ton of apps AND we can levarage Azure AD with Azure SQL, more details on my blog post on the subject here: https://accessexperts.com/blog/2017/10/16/ole-db-undeprecated-long-live-ado/

    1. For the 1st release we’ll only support multi-subnet and what SNAC 11 provided. So, the new release of OLE DB will not support Transparent Network IP Resolution, Always Encrypted, Azure AD Authentication, Bulk Copy and Table Value Parameters to begin with. We’re collecting feedback/scenarios on what to ad next based on customer priority, and I’d like to get your detailed feedback please.

      1. AccessKungFu says:

        Hi Pedro!

        Our top priority would be to enable login to Azure SQL with domain authentication, I realize this may not be in your next update but I hope it will be addressed early in 2018.

        Thanks!
        Juan

  3. Philipp says:

    Thank you! I truly welcome this decision. I have many applications using ADO/OLE DB for SQL Sever data access and am very happy now that this proven and solid data access technology will be supported in the future.

Skip to main content