History of ODBC
ODBC stands for Open DataBase Connectivity. It is a database middleware application which allows an application access data from a database.
Goals of ODBC
The SQL standard specified the statements that an application can use to store, retrieve or otherwise manipulate a database and its content. This standard though, doesn’t specify how an application should deliver the statements to a database server, or how to retrieve the database responses and content from the server.
This meant that while SQL statements could be standardised, and written to be vendor neutral, getting them in and out of the database still required the use of vendor specific interfaces. This effectively coupled an application to the database vendor, meaning that the application would have to have portions rewritten if another vendor’s database was to be used.
With the development of the ODBC middleware, applications have a database neutral means of delivering SQL to the database server. The main goal of ODBC was to provide a standardised way of providing a pipeline between applications and the databases they depended on.
Components of ODBC
Previous to the development of ODBC, the means by which an application accessed a database is shown below. An application would have to be written to issue vendor specific commands to a database server, perhaps across a TCP/IP network. The database responses would also be returned in a vendor specific way, and the application would need to know how to handle those too.
APPLICATION -> VENDOR SPECIFIC ACCESS PROTOCOL -> TCP/IP NETWORK -> DATABASE
ODBC, being a middleware technology, introduces another step, as shown below. Now the application issues standardised ODBC commands to an ODBC driver. This driver is matched to the database type being accessed, and translates those ODBC commands to the vendor specific protocols before passing them to the database.
APPLICATION -> ODBC DRIVER -> VENDOR SPECIFIC ACCESS PROTOCOL -> TCP/IP NETWORK -> DATABASE
The benefits of this means of accessing the database server, are that the application is now vendor neutral. The application is written to make use of the ODBC driver application programming interface (API). The ODBC driver translates those application commands into the vendor specific commands for the database type being accessed, it also translates the database responses, and returns standardised ODBC responses.
If the application is moved to a different database, then the ODBC driver and database are changed. No changes are required to the application. The new ODBC driver will ensure that the same ODBC commands are translated between the application and the database using appropriate protocols.
The Call Level Interface (CLI) developed by The Open Group was the de facto standard for accessing databases from C and COBOL and defined ways in which applications and database system should communicate with each other.
The CLI became the basis for the development of the ODBC standard. ODBC was accredited by both ANSI and the ISO in 1992, which lead to widespread adoption of ODBC by database vendors.
The SQLSummit.com website lists hundreds of ODBC drivers from numerous database vendors. One could even argue, that any new database being developed is not likely to survive without ODBC support, such is its widespread adoption.
Nance, B. Data Access Via ODBC and JDBC. 1999. Retrieved on May 30, 2007 from http://www.networkcomputing.com/netdesign/odbc1.html.
North, K., ODBC Drivers and Servers, 2006. Retrieved on May 30, 2007 from http://www.sqlsummit.com/ODBCVend.htm.
Wikipedia Contributors, Call Level Interface, 2007. Retrieved on May 30, 2007 from http://en.wikipedia.org/wiki/Call_Level_Interface.