ODBC and JDBC represent powerful magic. When I'm trying to explain ODBC, there is one demonstration I use that illustrates this magic. You create a directory consisting of just text files with data in them, and turn them into an ODBC source. You access the source via the ODBC driver, using an IDE that understands ODBC, or via code, and you can use those primitive text files as a relational database, accessing all that data via SQL Calls.

Despite the cryptic connection strings and the occasional unfathomable error message, ODBC is still the best way of getting communication going with an unfamiliar data source. It turns even unlikely material such as JSON files, Clipper, Ingres, Lotus Notes, ADABAS or LDAPs into standard SQL databases. It provides a translation layer between the application and the data source.

Despite Microsoft inventing and introducing what is now an international standard for interfacing with data, they have always been culturally lukewarm to the idea. The Microsoft drivers, with the notable exception of SQL Server's, have always been rather poor. Third-party providers have come up with a rich source of excellent drivers, but the Microsoft 'desktop database drivers' only just manage the minimum grammar to qualify as an ODBC driver. At the time that both ODBC and JDBC were enthusiastically adopted by Apple and the Linux platforms, Microsoft became distracted by creating a variety of rival proprietary call-level interfaces, such as OLE DB, ActiveX Data Objects (ADO) and ADO.NET.

Mercifully, SQL Server remains fully committed to the ODBC standard. Sadly, this isn't true of the entire data platform. Those who want to use DocumentDB, for example, have been campaigning for nearly two years for an ODBC driver. We now hear that the team is 'considering it'. Heavens, we can get ODBC drivers for MailChimp, Google Sheets, Facebook, Ebay, Paypal , SalesForce and YouTube. Why not DocumentDB?

For solving all those connectivity problems that beset us in the everyday life of database applications, there is a lot to be said for ODBC as a sort of universal quick-fix glue to tide us over until we can find a more robust solution (it doesn't supply enough information about the schema for complex applications). Tools that only deal with ODBC information will never rival tools that run queries on the native database. With ODBC/JDBC, however, we are close to an effective universal standard for data access across platforms, applications and data sources. It seems something that is worth achieving, and maintaining.

Phil Factor.