In the 1980s, every database and printer came with its own copyrighted programming interface. Any applications a customer bought or created could only work with specific versions of certain brands of databases or printers without needing to be re-purchased or modified and re-tested! If a customer merged with another enterprise that used different brands or versions of databases and printers, or if a new database or printer came on the market that had valuable features like stored-functions, cascading-triggers or double-sided printing, customers would have to build or buy new applications, or otherwise figure out how to modify their code. Interestingly enough, while MySQL, PostgreSQL and SQLite are all "free" software from the 1990s, they too have their own unique and incompatible programming interfaces just like the 1980s!

Vendors of mainframe and minicomputers loved this situation, because by simply bundling the database and printers with the computer system (such as Vax/Rdb or IBM IMS), customers became totally dependent and loyal. Some customers began to switch to UNIX, the only operating system of the day that ran across multiple vendor hardware and therefore became known as an "Open" system. From there, the customers and UNIX vendors formed groups such as the "Open Software Foundation SQL Access Group" to create standardized programming interfaces that should be adopted by all UNIX database vendors, but before that effort could really take off, the PC downsizing trend reached critical mass.

What is ODBC?

In Windows architecture, standardized programming interfaces allow any application to talk to any printer or database by way of a "manager" that has internal APIs that third-party databases and printers may implement to receive database queries or printouts and to return data, making them instantly compatible with any application, even those not yet developed. Customers are free to purchase any combination of printers, databases and applications without regard to the vendors, especially their PC vendor. The API that applications use on Windows to access the database "manager" (and that the database manager specifies for the third-party databases to implement) is titled "Open Database Connectivity" (ODBC) and is based loosely on the work of those early customers in the "SQL Access Group" back in the 1980s.

For Non-Windows architecture, in support of Microsoft's long-running Office for Mac product, the Windows ODBC Manager was eventually ported to Macintosh, initially as a plug-in that could be downloaded off Apple's site, then included in Office for Mac itself and more recently, shipped with every Mac sold. There were several failed attempts to recreate the Windows ODBC Manager for UNIX and LINUX, but they never caught on because for something with that level of binary-compatibility to succeed, the operating system must be organized in way that database vendors can depend on, which of course is not really the case when there are hundreds of available UNIX and LINUX distributions. Thus on UNIX and LINUX, it is common for ODBC-aware applications to directly link with ODBC-compatible "drivers", rather than to link with any sort of ODBC "manager" as they would on Windows or Macintosh. Unfortunately, most database vendors will not support Mac or LINUX with the same quality (if at all) as they provide for Windows and so ODBC-aware apps on those platforms (like PHP) pretty much need to connect to real Windows ODBC drivers installed on a back-end server (or VM), by directly linking with a so-called ODBC "overdriver" (that talks to a remote ODBC Router). In fact the only two ODBC "managers" ever produced for UNIX and LINUX (iodbc and unixODBC) were little more than "trojan horses" for similar technology that competed with ODBC Router, which is truly why the database vendors found no need to support UNIX or LINUX with native ODBC drivers.)

Next:
PHP and ODBC, How Does ODBC Work?