ODBC Driver Development

ODBC Driver Development

by Vikash Agarwal, May, 2002

Open your database system to the world. Vikash steps through developing an ODBC driver with 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 a application to access different databases, SIM ultaneously, 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 a ODBC driver for that DBMS. The client does not statically link with any ODBC driver; In Windows, the driver are implemented as a DLL allowing it to being loaded at run time. The name, parameters, and what these apis/functions was expected to does is defined by the ODBC standard. The use of drivers isolates applications from database-specific calls in the same to that printer drivers isolate word PR ocessing programs from printer-specific commands.

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

I developed my ODBC driver on Windows professional using Visual C + + 6.0, so all the extra tools and samples mentioned is from Microsoft unless otherwise noted. Microsoft groups ODBC together with it other data access technologies under MDAC (Microsoft Data Access Components). MDAC is available as part of the 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 has to use LoadLibrary and GetProcAddress for each driver you want to use. It performs some basic error checking before a call was 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 and the request conforms to syntax supported by the Associa Ted DBMS.
• The data source consists of the user wants to access and its associated operating system, DBMS, and NETW Ork 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 is a Oracle DBMS running on the 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, NE Twork address, network software, and so on-into a single place and hide it from the user. The user should is able to look at a list that includes Payroll, Inventory, and personnel, choose Payroll from the list, a ND has the application connect to the payroll data, all without knowing where the payroll data resides or how the Applica tion got to it. File data sources is stored in a file and is connection information to being used repeatedly by a single user or shared a Mong several users. WhenA file data source is used, and the Driver Manager makes the connection to the data source using the information in a. DSN fil E. This file can be manipulated as any other file. A file data source does not has a data source name, as does a machine data source, and was 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 oth Erwise has the to is built for a call to the sqldriverconnect function. Another advantage of the. dsn file is this it can be copied to any machine, so identical data sources can being used by many Machines as long as they has the appropriate driver installed. A file data source can also is shared by applications. A shareable file data source can be placed in a network and used simultaneously by multiple applications. DSNs created for individual users would be called User DSNs is registered in the following system Information key:

?

1234	HKEY_CURRENT_USER    SOFTWARE        ODBC            Odbc.ini

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

?

1234	HKEY_LOCAL_MACHINE    SOFTWARE        ODBC            Odbc.ini

Figure 1:the ODBC architecture.

The ODBC API is used in Places:between the application and the Driver manager, and between the Driver manager and EAC H 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 does not worry about the typical "too m Any 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'll discuss more on the ' This ' section "Packaging calls in Xml-soap and communicating over sockets". You'll need to has some idea about the XML and sockets in addition to the general C programming and DLL creation.

To do your database server work with your driver, a thin layer have to is added to it. This layer understands the XML-SOAP encoded calls from the driver; It interprets them to existing functions on 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 is free to use one of your choice with necessary changes to the sample Code.

It is important to understand the ODBC is designed to expose database capabilities and 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 could or may not be implement update and is not bound by any other engine. However, the driver for SQL Server are limited by the functionality provided by the SQL Server engine, since the driver its Elf never touches the raw data files.

I am going to create a driver for a server based DBMS, since the aim was only to expose existing functionality. Besides, I feel that a file-based DBMS have little to offer in today's Client-server world.

ODBC Driver Development