Two ODBC Server Options Installing the OpenChannel server was simple, but configuring it was far from straightforward. Most of the confusion arises from the fact that the server implements its data access through standard ODBC drivers, so you need to configure data source names (DSNs) correctly on both the client and server. This results in a two-sided ODBC driver setup. Also, because OpenChannel runs as an NT service, you need to make sure that the DSN is accessible to the account under which the NT service runs.

OpenLink, on the other hand, implements its database interface using each DBMS vendor's CLI. As such, it doesn't require configuring DSNs on both the server and client, but instead gets its configuration information from a single Windows .INI file. OpenLink runs a separate executable for each DBMS the ODBC server accesses.

Installing the client side of the se drivers is relatively simple; after all, it's just another ODBC driver. (By the way, both products support all the major client platforms.) All that's necessary for configuration is to define the DSNs that point to the ODBC server. Plan carefully which 16-bit and 32-bit driver versions you need to install for the respective clients. This easily can become an endless source of trouble. For example, if you've previously installed a 16-bit ODBC application on an NT machine, it's possible the 16-bit ODBC administrator is resident, and it will not allow you to install the 32-bit drivers these products require.

These servers do not alleviate the burden of configuring DSNs on the client. This is required for each database you want the client to access; however, each of those DSNs need only one client ODBC driver and only one set of network libraries. Don't underestimate this requirement as it's likely you'll change these more often than adding or removing entire DBMS servers. It would be a significant improvement if these clients could query a set of DSNs from the server and configure themselves.

Using standard ODBC drivers on the server or database-specific agents has a large impact on the architecture of the ODBC server itself. With the former, you can take advantage of the wide selection of ODBC drivers for virtually any data source available. In addition, session concurrency is entirely dependent on the ODBC drivers that are used between the ODBC server and the data source. If this driver is not thread-safe, ODBC cannot spawn separate threads for different sessions and must serialize access to the data source. This can have a significant impact on the gateway's performance.

In the second case, you're dependent on OpenLink to provide the CLI drivers for you. This limits you to what OpenLink has to offer, but it has been able to take advantage of some performance enhancements. For example, its ODBC server acts as broker. Once the session is negotiated by the ODBC server, all communications take place between the client and the database agent. The OpenLink database agents don't have the concurrency problems of some standard ODBC drivers.

Since ODBC servers essentially provide the network middleware, OpenChannel and OpenLink provide their own database network protocol for communication between their clients and servers. Both OpenChannel and OpenLink use TCP/IP, but OpenLink has begun to include support for IPX/SPX as well. This is set up and configured automatically (presuming you have TCP/IP installed on your machines).

Finally, security has always been a concern with ODBC. Beyond authentication, ODBC doesn't specify any additional security, particularly for end-to-end encryption. This is entirely dependent on the underlying vendor middleware, and if not implemented, ODBC transmits sensitive data in the clear. With OpenLink we established a secure channel simply by turning on an encryption flag in the configuration files of both the client and server. OpenChannel products provide secure connections as options to its base package.

The Long and Short of It It's easy to say that Microsoft should have designed the ODBC specification with this kind of architecture from the beginning. But with the state of data-access middleware at the time ODBC was released (fractured, proprietary), it's also easy to see the logic of Microsoft's approach. Microsoft wasn't interested in developing the network-level protocol that is essential to these products. The standard API was the only goal.

The ease of administration that ODBC servers offer is clear, but there are some trade-offs, the most significant of which is being tied into a single vendor solution for your ODBC data sources and data access network transport (as with OpenLink). Cost is another factor. Visigenic's OpenChannel comes in at approximately $500 per user, a hefty price for easy ODBC administration.

Anthony Frey can be reached at afrey @nwc.com.