If you have a DBMS server from only one vendor, this is a much smaller problem. But this most likely is not the case as the entire point behind ODBC is being able to access more than one type of data source for all applications. This is just one of the headaches that you can encounter.

One way of solving this problem is using ODBC servers (also known as "server-side ODBC drivers"). This requires installing only a single ODBC driver on each client. We tested how well these work using a Microsoft Windows NT 3.51 Server, a Sybase SQL Server 10 database and OpenLink Software's OpenLink and Visigenic Software's OpenChannel as ODBC servers. There are others, such as Ensod ex's HotSockets and DataRamp's DataRamp Server.

Serving Up the ODBC Architecture Let's take a look at a traditional ODBC setup to see how these new drivers fit into the architecture. ODBC is a layered architecture (see "Standard ODBC Architecture" below). The three client-side layers provide the API to the application as well as define data sources for their use. Most of us are familiar with the Driver Manager. This is the visible part of ODBC, where drivers are added and data sources configured on each client.

Below the Driver Manager are the ODBC drivers themselves. These are the specific components that interface with individual data sources. There are two types of drivers: single tier and multitier. Single-tier drivers usually are used to access flat file data sources. All logic for data access and query processing is in the driver itself.

In contrast, multitier drivers contain the logic to interface over the network using the database server-specific middleware. Of course, each database vendor's middleware product (SQL*Net, DB-Library, OpenClient, etc.) also must be installed. This whole driver portion--from the ODBC driver through the network layers to the data source itself--is the most complex part of the ODBC architecture.

With an ODBC server (see "ODBC Server Architecture," on p age 134), we have the same logical layers as a normal ODBC setup. But now we need install only one driver on each client. This is a driver to access only the ODBC server. On the server you have to install a driver, often called a database agent, for every data source, but that administration task is far easier than updating your entire client base. You still can install single or other multitier drivers alongside the server driver, but there is no reason to if there is a database agent available for the ODBC server.

It won't be mentioned in the product literature, but these servers in effect are simply setting up an ODBC gateway. Standard ODBC drivers have proven to be fairly efficient, comparable to most database vendors' own call-level interface (CLI) APIs. Can these gateways maintain the same performance? Yes. Why? Because vendors have been optimizing standard ODBC drivers since their inception and they bring this technology to ODBC servers. A couple of implementations have other specific advantages t hat we'll see later.