Recently Microsoft announced in a blog post that it is deprecating OLE DB stack in SQL Server Native Client and shifting focus to ODBC. Given that I own SQL Server Native Client product at Microsoft I'd like to take a few minutes to clarify what is actually happening and why industry shouldn't panic.

After reading original blog post and various interpretations by different people on the internet one might think that OLE DB as technology is being deprecated. This isn't true. Only a concrete implementation is being deprecated, namely SQL Server Native Client's OLE DB stack. If you are familiar with SQL Server Native Client it comes with two database access stacks packaged in a single DLL - OLE DB and ODBC. Only OLE DB stack is being deprecated, that's it. OLE DB as a database access technology lives on. A miriad of OLE DB providers written since OLE DB inception will continue to work on Windows after SQL Server codename 'Denali' ships.

I'd also like to point out a distinction between deprecation announcement and removal. Even though OLE DB stack in SQL Server Native Client is being deprecated, it is not being removed any time soon. You can still use it when you upgrade to SQL Server Native Client Denali. Moreover, I would strongly enocunrage everyone using previous versions of SQL Server Native Client to upgrade as there will be a lot of improvements spanning functionalily, performance, scalability and robustness.

Linked SQL Servers

I'd like to ensure everyone that backwards compatibility in linked servers functionality will be preserved in SQL Server Denali. Both Microsoft SQL Server Native Client OLE DB provider and all 3rd party providers that used to work before will continue to function.


SQL Server Integration Services, Reporting Services and Analysis Services will continue to operate and serve your business needs. Even in many years when OLE DB code from SQL Server Native Client will be removed, Microsoft will provide a solution to ensure minimum impact on your business.


There are quite a few questions about ADO.NET's OLE DB wrapper, namely System.Data.OleDb. As far as I know this bridge is not going anywhere with SQL Server Native Client's OLE DB stack deprecation. You can still use it if you need to interop from managed code into native OLE DB provider. Some people get confused (and rightfully so) between stacks and don't know where's the safe heaven. General rule of thumb is quite simple actually - if you're developing a native C++ application then please use ODBC technology to access data in the SQL Server. However, if you are writing a .NET application in C# or VB.NET, either console, or web application, please use System.Data.SqlClient. There's no need for you to install SQL Server Native Client and interop into native stack through either System.Data.OleDb or System.Data.Odbc. SqlClient is the way to go. It also means that you shouldn't jump on System.Data.Odbc if you were using System.Data.OleDb. Please carefully evaluate your requirements and make a call. For example, if you are using a 3rd party OLE DB stack that doesn't have ADO.NET implementation then no action is required on your side.

I'd like to close this article on a positive note. SQL Server Native Client OLE DB deprecation is in fact a good thing.  Instead of confusing customers even more Microsoft decided to invest havier in one stack and make it awesome as opposed to two stacks which would only be great. Yes, there will be certain discomfort along the way, but sometimes tough choices are necessary.

Disclaimer: Don't take my words as official Microsoft commitment. This article describes current state of affairs which may change in the future.