The Return of ODBC: Boom or Bust?
Microsoft has been quietly working to revive an old but trusted data access technology that some thought it had left for dead -- Open Database Connectivity or ODBC.
The popular API for providing SQL access to C and C++ applications (as well those built in other languages), ODBC has remained dormant for the better part of the past decade after Microsoft shifted emphasis to its COM-based OLE DB. Microsoft recommitted to ODBC two years ago and, in January, released ODBC 3.8 in beta 1 of the Windows 7 SDK .
Besides adding support for SQL Server 2008, the new release provides bug fixes and three key improvements: 1) asynchronous operations, which should lend itself well to occasionally connected applications and those connected to cloud-based services; 2) streamed output parameters for retrieving large blocks of data and 3) support for C data type extensibility.
The latter will allow those who build drivers to create their own data structures that they can return to an application that don't now exist in ODBC, explained Rob Steward, vice president of research and development at DataDirect, a subsidiary of Progress Software Corp.
"It's good for driver-writers such as myself or the database vendors in that they may create types that may not exist in the specification," said Steward whose company this week released a set of ODBC drivers. Still he questions whether it's good for ODBC overall.
For example, in the case of a time stamp data type representing different time zones, "the original ODBC specification doesn't have a very clean way to return that, but a driver-writer may then create their own structure, with which to return that time zone data," he said. The problem is that it creates sort of a trap for ODBC developers.
"If you use the types the driver vendors create, now your application and your code only works with that one driver, which defeats part of the purpose of ODBC," he said. "So it's kind of a built-in way for people to extend the spec on their own, which again is good and bad but overall that was the big value of ODBC -- that you can write a single set of code that works against multiple databases."
Steward is concerned that with these driver specific C data types, "your code doesn't work against multiple databases, it only works against one driver," he said.
But that shouldn't be a problem, so long as Microsoft's changes don't affect the driver manager, said Amyn Rajan, president and CEO of Vancouver-based Simba Technologies Inc., which builds ODBC drivers for ISVs. David Sceppa, Microsoft's ADO.NET program manager, was not available for comment.
"The real risk is about changes they are making in the driver manager -- this is code that probably hasn't been touched in at least a decade," Rajan said. So far, in its tests with the new ODBC driver in the Windows 7 SDK Simba's engineers haven't found any problems.
Rajan says he finds it interesting that after years of effectively trying to cast aside ODBC in favor of OLE DB, that Microsoft has come back to ODBC. "The fact that they are extending ODBC tells me they actually decided ODBC was something that was good and something they are going to invest in and they look at this as a first class API," he said. "If they were trying to kill ODBC, they would have added this functionality to their .NET provider."
Will ODBC make Windows 7 a better client for accessing data-driven applications and content? Are Steward's concerns about the potential for C data type extensibility a concern? Drop me a line at jschwartz@1105.com.
Posted by Jeffrey Schwartz on 03/26/2009