ODBC Driver Development

By Vikash Agarwal, May 01, 2002

Open your database system to the world. Vikash steps through developing an ODBC driver, using XML-SOAP for encoding the calls and results. The communication between the driver and DBMS takes place over sockets.

The primary design goal of ODBC (Open Database Connectivity) is to allow an application to access different databases, simultaneously, with the same source code.

An ODBC client always calls a fixed set of APIs to access data from any ODBC-compliant DBMS. The APIs for each DBMS together form an ODBC driver for that DBMS. The client does not statically link with any ODBC driver; in Windows, the driver is implemented as a DLL allowing it to be loaded at run time. The name, parameters, and what these APIs/functions are expected to do is defined by the ODBC standard. The use of drivers isolates applications from database-specific calls in the same way that printer drivers isolate word processing programs from printer-specific commands.

The aim of this article is to help you create an ODBC driver for your DBMS. I will discuss the ODBC architecture and then create a simple ODBC client. This will give you an idea of what is expected from your driver. Then we will proceed to create the driver itself.

I developed my ODBC driver on Windows 2000 professional using Visual C++ 6.0, so all the extra tools and samples mentioned are from Microsoft unless otherwise noted. Microsoft groups ODBC together with its other data access technologies under MDAC (Microsoft Data Access Components). MDAC is available as part of Platform SDK or as a separate download at http://www.microsoft.com/data/whatcom.htm.

ODBC Driver and Architecture

The ODBC architecture has four components:

The Application performs processing and calls ODBC functions to submit SQL statements and retrieve results.
TheDriver Manager is a DLL provided on a Windows platform as part of the ODBC components. It manages certain tasks common to all ODBC clients. For example, it manages loading and unloading of driver DLLs, and creation and maintenance of pointers to driver functions so you don’t have to use LoadLibrary and GetProcAddress for each driver you want to use. It performs some basic error checking before a call is forwarded to the driver and also implements certain functions like SQLDataSources, SQLDrivers, and SQLGetFunctionswithin itself.
The Driver processes ODBC function calls, submits SQL requests to a specific data source, and returns results to the application. If necessary, the driver modifies an application’s request so that the request conforms to syntax supported by the associated DBMS.
The Data source consists of the data the user wants to access and its associated operating system, DBMS, and network platform (if any) used to access the DBMS.

Using a Data Source

A data source is simply the source of the data. It can be a file, a particular database on a DBMS, or even a live data feed. For example, a data source might be an Oracle DBMS running on an OS/2 operating system, accessed by Novell Netware; an IBM DB2 DBMS accessed through a gateway; a collection of Xbase files in a server directory; or a local Microsoft Access database file. The purpose of a data source is to gather all of the technical information needed to access the data — the driver name, network address, network software, and so on — into a single place and hide it from the user. The user should be able to look at a list that includes Payroll, Inventory, and Personnel, choose Payroll from the list, and have the application connect to the payroll data, all without knowing where the payroll data resides or how the application got to it. File data sources are stored in a file and allow connection information to be used repeatedly by a single user or shared among several users. When a file data source is used, the Driver Manager makes the connection to the data source using the information in a .dsn file. This file can be manipulated like any other file. A file data source does not have a data source name, as does a machine data source, and is not registered to any one user (UserDSN) or machine (SystemDSN).

A file data source streamlines the connection process, because the .dsn file contains the connection string that would otherwise have to be built for a call to the SQLDriverConnect function. Another advantage of the .dsn file is that it can be copied to any machine, so identical data sources can be used by many machines as long as they have the appropriate driver installed. A file data source can also be shared by applications. A shareable file data source can be placed on a network and used simultaneously by multiple applications. DSNs created for individual users will be called User DSNs are registered in the following system information key:

HKEY_CURRENT_USER

SOFTWARE

ODBC

Odbc.ini

Similarly, system DSNs are tied up to a particular system, and any user of that system can use them. System DSNs are registered in the following system information key:

HKEY_LOCAL_MACHINE

SOFTWARE

ODBC

Odbc.ini

Figure 1: The ODBC architecture.

The ODBC API is used in two places: between the application and the Driver Manager, and between the Driver Manager and each driver. The communication between the driver and the data source is the individual vendor’s choice. Note that you can create, implement, and use a driver without the driver manager, so do not worry about the typical “too many layers” situation.

The driver packages the API calls along with the parameters and sends it to the DBMS or data source. The DBMS processes the call and sends the results back to the driver, which throws back the results to the ODBC clients. I am going to use XML-SOAP for encoding the calls and results. The communication between the driver and DBMS takes place over sockets. We will discuss more on this in the section “Packaging calls in XML-SOAP and communicating over sockets”. You will need to have some idea about XML and sockets in addition to general C programming and DLL creation.

To make your database server work with your driver, a thin layer has to be added to it. This layer understands the XML-SOAP encoded calls from the driver; it interprets them to existing functions in your DBMS engine and encodes back the results as XML-SOAP. The core of this layer is an XML parser. The parser is also required as part of your driver. I have provided one in the download, but you are free to use one of your choice with necessary changes to the sample code.

It is important to understand that ODBC is designed to expose database capabilities, not to supplement them. It makes your DBMS accessible to more clients through a commonly accepted standard. One exception to this is a file-based driver, which works with raw data and therefore also implements the functionality. A driver working on a DBF file may or may not implement update and is not bound by any other engine. However, the driver for SQL Server is limited by the functionality provided by the SQL server engine, since the driver itself never touches the raw data files.

I am going to create a driver for a server based DBMS, since the aim is only to expose existing functionality. Besides, I feel that a file-based DBMS has little to offer in today’s client-server world.