Microsoft Open Database Connectivity (ODBC) specification was created with a view to making it easier for an application developer to write systems involving communication with different types of databases.

The objective was to make it possible to develop an application system that would work unchanged with a variety of different databases. Although it was originally designed by Microsoft, it is now supported by all major database vendors and is subject to international standardisation.

ODBC consists of an API (Application Programmer’s Interface; a standard set of functions that interface with some other software layer) and a set of drivers that provide communication between the API and the database.

Take a look at my simple diagram below which shows an example ODBC architecture:

The application programs use the set of functions defined by the ODBC API (the API is defined as C language functions). These communicate with drivers (implemented as dynamic link libraries) that are specific to the database being accessed.

The Access package itself can communicate with the ODBC drivers, either using Access Basic or by using built-in GUI procedures.

Using ODBC enables communication with one or more different database types within one application system. This is particularly convenient when attempting to build upon an older application system by intergrating it with newer database technology; the old and the new can operate side by side prior to a phased removal of the older system.

When used with Microsoft Access, it provides two main facilities; attached tables and pass-through queries, which operate in quite different modes. Access allows database tables belonging to other systems to be attached to an Access database.

This means that Access treats these tables as if they were conventional Access tables; they can be queried, joined, updated, etc., in the same way as native Access tables. Using the pass-through facility, queries (in SQL) are sent directly to a database server. No attachment of tables takes place.