Microsoft’s recent announcement that they would focus more on ODBC and deprecate OLE DB has raised a lot of questions. Amina Saify at Microsoft recently posted some questions and answers. Some interesting points were:
1. “When it comes to uniform data access to SQL Server from different platforms, ODBC has always been a better choice and that was consistently quoted by all of our customers in various surveys, SDRs and forums. By fully aligning with ODBC, Microsoft will be focusing on one set of industry standard APIs that are widely used by many of our customers.” This is a very powerful statement. At Simba, as the leader in data connectivity, people are always asking us what open standards based interfaces they should implement for their databases and data sources. My answer has always been ODBC first followed closely by JDBC.
2. “More customers are adopting cloud these days. To enable client applications running on various different platforms to connect to cloud, Microsoft chose ODBC as the de-facto standard client connectivity API for native client applications connecting to SQL Azure.” I am curious as to what Microsoft’s position is around JDBC access to Azure?
3. ” In most of the performance comparison tests we have done, ODBC seem to perform better.” Not only does ODBC perform better, it is also supported on pretty much any platform out there – Windows, Linux, Solaris, HP/UX, AIX, and MacOS. Talk about ubiquity.
You can read Amina’s post here: Microsoft is Aligning with ODBC for Native Relational Data Access or and I have reproduced it below as well:
Question1: Microsoft created OLE DB after ODBC, isn’t deprecating OLE DB a step going backwards?
Answer: Microsoft has been supporting ODBC through all the releases of SQL Server for relational data access. This includes adding new functionality to the ODBC drivers whenever a corresponding feature is added to SQL Server. OLE DB was introduced primarily to provide uniform data access to non-relational data as well as relational data. But it is a Microsoft proprietary technology that worked only on Microsoft platforms. When it comes to uniform data access to SQL Server from different platforms, ODBC has always been a better choice and that was consistently quoted by all of our customers in various surveys, SDRs and forums. By fully aligning with ODBC, Microsoft will be focusing on one set of industry standard APIs that are widely used by many of our customers.
Question2: Why is Microsoft making this change now? What are the advantages?
Answer: More customers are adopting cloud these days. To enable client applications running on various different platforms to connect to cloud, Microsoft chose ODBC as the de-facto standard client connectivity API for native client applications connecting to SQL Azure. If you are writing applications that run against standalone SQL Server and SQL Azure, or if you are planning to port your application to SQL Azure, using ODBC APIs make the transitions pretty seamless. ODBC APIs use industry standard interfaces and are very simple and straight forward to use. Using multiple result sets, memory management and specifying required/optional properties in OLE DB is more complex. Overall, customers get the benefit of easy programming and cross-platform support with this alignment and can now build applications that can be uniformly ported between various platforms.
Question3: How long will the current SQL Server OLE DB provider be supported?
Answer: SQL Server OLE DB will be supported for 7 years from the Denali launch, the life of Denali support, to allow you a large window of opportunity for changing your applications before the deprecation. It will also be supported through the complete life of Denali extended support.
Question4: What is being deprecated? What happens to other Microsoft products that use and depend on OLE DB?
Answer: This announcement is about the deprecation of Microsoft SQL Server OLE DB provider only. Other Microsoft OLE DB providers, 3<sup>rd</sup> party OLE DB providers and the OLE DB standard will be supported as per their respective terms. Other Microsoft SQL Server features and products that are built on top of OLE DB or use OLE DB, like Distributed Query (Linked Server), SQL Server Integration Services, SQL Server Analysis Services etc., will continue to be supported as per their respective terms. Microsoft will take care of replacing the underlying dependency. Providers like ADO.Net which can run on top of OLE DB will not support OLE DB once the latter is deprecated. At that time the clients using the underlying provider need to update their application to use a different provider.
Question5: Are there any features in OLE DB that are missing in ODBC? How about performance?
Answer: Most of the features related to relational data access in SQL Server are already available in ODBC. The specific implementation and usage may be different between these providers and if there are features that have better implementation in the current OLE DB, Microsoft will port such functionality to ODBC based on customer demand and feedback. In most of the performance comparison tests we have done, ODBC seem to perform better. We will publish a more detailed performance analysis document in the coming months.