Drivers

Drivers are libraries that implement the functions in the ODBC API.   Each driver is customized for a specific DBMS. Therefore, they are not interchangeable. For example, a driver for Oracle cannot directly access data in an Informix DBMS. Drivers expose the capabilities of the underlying DBMSs. Since drivers are customized for a single data source, they typically limit their implementation of the ODBC API to the capabilities of the underlying data source for which they are written. For example, if the underlying DBMS does not support outer joins, then neither should the driver. The only major exception to this is that drivers for DBMSs that do not have stand-alone database engines, such as Xbase, must implement a database engine that at least supports a minimal amount of SQL.

Specific tasks performed by drivers include:

• Connecting to and disconnecting from the data source.

• Checking for function errors not checked by the Driver Manager.

• Initiating transactions; this is transparent to the application.

• Submitting SQL statements to the data source for execution. If necessary, the driver will convert ODBC SQL to data source-specific SQL before it submits it to the data source for processing. Often, this conversion is limited to replacing escape clauses with the appropriate data source-specific SQL.

• Sending data to and retrieving data from the data source, including converting data types as specified by the application.

• Mapping DBMS-specific errors to ODBC SQLSTATEs.

Driver architecture falls into two categories, depending on which software processes SQL statements:

File-based drivers. The driver accesses the physical data directly. In this case, the driver acts as both driver and data source. That is, it processes ODBC calls and SQL statements. For example, dBASE drivers are file-based drivers because dBASE does not provide a stand-alone database engine the driver can use. Excel drivers also fall into this category.

DBMS-based drivers. The driver accesses the physical data through a separate database engine. In this case the driver processes only ODBC calls. It passes SQL statements to the database engine for processing. For example, Oracle, Microsoft SQL-server and Microsoft Access drivers are DBMS-based drivers because these DBMS have stand-alone database engines the driver uses. Where the database engine resides is immaterial. It can reside on the same machine as the driver or a different machine on the network. It might even be accessed through a gateway.

Driver architecture is generally interesting only to driver writers. It makes no difference to the application. However, the architecture can affect whether an application can use DBMS-specific SQL. For example, Microsoft Access provides a stand-alone database engine. If a Microsoft Access driver is DBMS-based (it accesses the data through this engine) the application can pass Microsoft Access – SQL statements to the engine for processing.

However, if the driver is file-based, that is, it contains a proprietary engine that accesses the Microsoft Access .mdb file directly, any attempts to pass Microsoft Access – specific SQL statements to the engine are likely to result in syntax errors. The reason is that the proprietary engine is likely to implement only ODBC SQL.