Before the creation of standards like ODBC, every database and printer still came with its own proprietary programming interface. Any applications
Here in 2010, while MySQL and PostgreSQL are "free" software, they too have their own unique and incompatible programming interfaces causing the same kinds of issues that were seen in the 1980s, especially
now that MySQL may be
destabilizinga customer bought or created would only work with the exact version of the specific brand of database or printer it was developed for. When a customer merged with another enterprise that used different brands or revisions of databases or printers, or if a new database or printer came on the market with new and valuable features, or if the customer changed computer vendors then the customer would usually have to build or buy all new applications. The mainframe and minicomputer vendors of the day loved this situation, because it allowed them to
lock-in their customers forever, simply by bundling an often
free proprietary database and printer with their computer systems:
"The first one is always free."
Large groups of customers began to switch from proprietary operating systems to UNIX, which was the only operating system of the day that ran across hardware from competing vendors and thus became known as a so-called "Open" system. From there, customers formed working groups such as the "Open" Software Foundation
SQL Access Group to create a SQL
Call-Level Interface (CLI) that they hoped to require their database vendors to implement, so that all applications on UNIX would interoperate with all database servers. Before that initiative could really take off, the
industry-wide PC downsizing-trend reached a critical mass and Microsoft created a Windows alternative based on their efforts, so all Windows apps would interoperate with all databases. That alternative is called
Open Database Connectivity (ODBC) and is the only such standard embraced by all database vendors.
On Windows, applications wanting to use a database or printer are (as a practical matter)
required to the use the official APIs exposed by the Windows ODBC and Print
Managers. Those
Managers then internally map the API calls onto to third-party
drivers supplied by the database or printer vendors. Those
drivers, in turn, map the API calls to the underlying proprietary database or printer. This "allows" any Windows application, even those not yet developed, to work with any database or printer while commoditizing the database vendors and printers who must now depend upon Windows compatibility for survival.
While it's true that most database vendors, even
open-source vendors, only provide
non-Windows platforms with
proprietary database APIs, the solution is to
download ODBC Router Network Service into the background of a central Windows VM or PC along side their official Windows ODBC driver. From there,
download the free
client-side component to your Mac or Linux servers (and on Linux, also recompile PHP
--with-ODBCRouter) and then all of your PHP scripts may pass SQL queries to any database using the
de facto industry standard ODBC API. What's more is that when the database vendors release updates, or when organizational mergers take place requiring different databases or when network changes suddenly happen, all such driver reconfiguration will normally only take place in the
ODBC Administrator control panel on the remote Windows box hosting ODBC Router, not in the PHP source code or on your Macs and Linux boxes.
Because the database vendors won't embrace them with an adequate level of support, they are no longer viable. The longer story: for
non-Windows architectures, initially on the Mac, chiefly in support of Microsoft's long-running
Office for Mac product, the ODBC Manager was eventually re-created by third-parties. It first appeared as an
extension that could be downloaded off of Apple's website, then included in
Office for Mac itself, then shipped with every Mac sold for a while, before being removed from Mac OS X and going back to being a
quasi-open-source project that was ported around to various Unix variants and LINUX distributions to compete against some other variants of itself written by other third-parties who had originated their efforts on LINUX and were, in fact, porting the other direction (to the Mac). Confused? It turns out that the people involved in creating all of those "free" ODBC Managers had long hoped to make a profit by selling and supporting
non-Windows ODBC drivers for all of the various versions of every major database system out there. Ultimately, none of this complexity made sense because, in the end, they could not keep up with the changes coming from the database vendors (without resorting to tricks like launching Java virtual machines in the background on the CPU) and the database vendors themselves were (and remain) too pre-occupied with competing against Microsoft's low-cost SQLServer (and the newer, even lower-cost, ORACLE MySQL product) to dedicate sufficient resources to maintaining
non-Windows ODBC drivers. The End.