ODBC was first created in 1992 as a generic set of standards for providing access to a wide range of data platforms using a standard interface. ODBC used to be a common interface for accessing SQL Server data in earlier days. However over the last 15 years ODBC has been second fiddle as a provider for SQL Server application developers who have usually favoured the platform specific OLE-DB provider and the interface built on top of it such as ADO.
ODBC was first created in 1992 as a generic set of standards for providing access to a wide range of data platforms using a standard interface. ODBC used to be a common interface for accessing SQL Server data in earlier days. However over the last 15 years ODBC has been second fiddle as a provider for SQL Server application developers who have usually favoured the platform specific OLE-DB provider and the interface built on top of it such as ADO.
Now in an apparent reverse of direction various Microsoft blogs have announced the next version of SQL Server will be the last to support OLE-DB with the emphasis returning to ODBC. Why this is the case isn’t entirely clear but various people have tried to answer this, the primary message being that ODBC is an industry standard whereas OLE-DB is Microsoft proprietary. And as they are largely equivalent, it makes sense to only to continue to support the more generic of the two providers.
After years of developers moving away from ODBC to OLE-DB, as you would expect this announcement is being met with much surprise in the community. But to be fair I suspect most developers won’t notice as they user higher level interfaces, such as ADO.NET, which abstract the specifics of the underlying providers. C/C++ developers on the other hand may need to revisit their data access interfaces if they are directly accessing SQL Server via OLE-DB.