Data Access and the Road to ADO.NET

All commercial database management systems (DBMSs), such as Microsoft SQL Server, Oracle, and IBM DB2, include some kind of API for accessing the data they contain. So the simplest way to build an application that calls any of these DBMSs is to use the API included with the database.

However, this approach has several limitations that make it impractical. First, it makes combining data from multiple DBMSs difficult because developers must deal with different APIs for each product—for example, if a table of customer information is stored in DB2 and the orders table in Oracle, then an order tracking application becomes quite difficult to develop. Second, data might be stored in a nontraditional data store for which no standard API exists (ranging from large mainframe databases to simple Excel spreadsheets or text-based files). Without some intermediary service, developers would be forced to access the file directly to extract information.

ODBC Provides Database Independence

These problems led to the development of the Open Database Connectivity (ODBC) API. ODBC defines a middle layer (called an ODBC driver) between an application and the DBMS. Database vendors and third parties have written ODBC drivers for various relational DBMS products that allow developers to access those databases through a standard API based on the C programming language. In addition, vendors have developed ODBC drivers that support mainframe databases, such as VSAM and IMS, and that read and write non-DBMS formats, such as text files and Excel spreadsheets. This allows developers to target a wide range of DBMSs with a single API set.