A plea to developers writing drivers for IB.

    In the past weeks (this was written on 2000-Dec-26), I've been taking a look and using some of the different offerings of connectivity for IB on Windows. Since I need to interface with IB from web servers (and particularly from IIS, using ASP and ADO), I concentrated on the ODBC and OLE/DB drivers for Windows.

I don't intend to comment this time on my experiences with several of those drivers; maybe in the future. For now, I want to explain some basic measures developers of database drivers should take to avoid possible clashes.

For anyone that has taken a quick view of NT organization, it's clear that usually, operating system drivers are in winnt\system32\drivers and this directory is reserved for drivers the operating system relies on, regardless of whether the author is MS or the company that provides the driver for its own HW. This leaves the issue of drivers that aren't needed by the OS to work. Those go in masses in the winnt\system32 directory, where the majority of NT commands and DLLs are located. Aleksey Karyakin has pointed out that since the full path of the drivers go into the registry, they don't have to be put on the system32 directory, but in any place the developer chooses. Probably this extra configuration step is done for bloated driver installations for other engines, but in the case of IB, where one file or a few files are needed, this seems overkill. In practice, none of the current ODBC or OLE/DB drivers for IB use another directory than the system32 one.

In the early days of Win3.1 (or Win 16-bits, if you prefer), settings that didn't go in their own proprietary file in the directory of the application that used them, were stored in INI files in the windows directory. It's true that INIs can be created on any directory, but this doesn't change the basic issue: INI are text files with another extension, editable by every text editor. In such ancient times, the critical Windows initialization files were named win.ini and system.ini. But we had also Odbcinst.ini and Odbc.ini, that not surprisingly, hold information about ODBC drivers installed and ODBC drivers setup. With the advent of NT, the registry became the de facto hierarchical database for storage of operating system, drivers and application settings. Hence, the registry has subkeys named
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI
that store user DSNs, system DSNs and driver setup information, respectively. Today, NT still maintains automatically a degree of compatibility and synchronization between those registry subkeys and the INI files described previously. Also, MDAC packages in versions after 2.1 have renamed the ODBC applet to become the "Data Sources (ODBC)" applet in the Control Panel. Curious people may wonder why ODBC information is not stored inside
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ODBC
or inside
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ODBC
even though it's a technology developed initially by Microsoft. The only answer I can guess is that MS wants the enforce the fact that ODBC is an accepted standard that spans UNIX and Windows, regarding of its origins.

Despite MS usage of the registry and its newer MSI technology, database drivers have the same possible problems than before. There are two main sources of clashes:

• The registration name of the driver in ODBCINST. It determines the identification string your driver uses to be listed in Control Panel (if registered to be visible and configurable in it) and/or the name a developer should use to refer to it directly without having a persistent DSN, what's called in the documentation as DSN-less connection, where you specify all important parameters directly.
• The name of the driver itself and its possible support files. Since those aren't operating system drivers, usually they are DLLs and are stored in the winnt\system32 directory. Therefore, they are subject to the classic "DLL HELL" that menaces developers like a jackal since several years ago. They can be stored with the application that needs them, but usually database drivers are meant to be shared by applications to provide connectivity even to web servers, so they go usually in the system32 directory. Otherwise, you would need soon to include several of your applications' directories in the search path of the operating system, only because they contain some widely used DLL. 

It's true that Win2K and its successor (code named whistler) are trying to improve in this regard, so applications can have their own DLL versions, but this defeats largely the idea behind DLLs: not only being loadable on request but being shared among several applications.

I think the sane conclusion is to avoid possible clashes in advance. So, my plea is: avoid generic registration names that can be chosen easily by other developers. Don't register your driver as "InterBase driver" or "Interbase ODBC driver" or "IB OLE Provider" because there's no guarantee others can't select the same name by accident. Also, avoid generic file names, like "IBdriver.dll" or "ibprovider.dll" that again, can be chosen by another developer. Just because you think you started to develop first, don't use this as an argument to take over a generic name. Other company or independent developer may give the same name in good faith to his/her creation. Remember, the market for IB is not very well known: if you don't know about all others working in parallel with you to produce a driver for IB, chances are the others don't know about you or don't think you are the first. Even if they think your driver is the first that started being developed, they might not agree that yours is the better and that you have the right to use "the name". So, please, put the ego aside and build a name that cannot be easily picked by another developer. This includes both the driver name (and associated files, when they aren't generic DLLs that come from the development tool to be redistributed but files made by you, too) and the driver registration name. Use your name, your company's name, your city's name or simply a name you like, but choose some prefix for your files and ODBC registration.

When I asked Nick Gorham from Easysoft, he told me his driver carries a unique identification since day one. Later, on Tuesday 26, Dec-2000, Nick told me their driver uses ib6odbc.dll and ib6odbcS.dll, and calls itself "Easysoft IB6 ODBC". Personally, I don't deem the names to be much generic, but there's no candidate to clash for now. When I asked Roman Vanicek from XTG Systems, he replied «Our driver registers with Windows as 'XTG Systems InterBase6 ODBC driver' and the name of the library is ib6xtg10.dll (standing for XTG driver for IB6 version 1.0).» On Friday 15, Dec-2000, Aleksey Karyakin replied to my prior concerns about his driver that he had decided to register it as "Gemini InterBase ODBC Driver" to distinguish it from other products. The prior version I have uses a not so very same library name "ibdrv.dll" but I don't know if he added a prefix, maybe a G to the driver name, too in his latest release. When I tried the OLE/DB provider from Márcio Wesley Borges (company name?), the name of the driver was SIBProvi.dll and there's no registration or setup available from the Control Panel yet (all work is done in a DSN-less way). On Wednesday 12, Dec-2000, Dmitry Kovalenko from Lipetsk Centre replied that the new registration will be LCPI.IBProvider to avoid registration clashes. The driver is contained in a file called _IBProvider.dll; I don't know if the underscore suffices, but certainly is a first step to avoid file name clashes. The Starkey's driver (IBPhoenix driver) is contained in the files OdbcJdbc.dll, OdbcJdbcSetup.dll and IscDbc.dll; I don't know if there's an odbc to jdbc bridge whose driver might clash with those DLLs. The driver registers as OdbcJdbc although I would prefer some prefix, like the initials of the author or a P from Phoenix, to provide extra safeness against clashes. This seems to be the only driver that doesn't carry "IB" in its name.

Remember, there's no guarantee that only one driver will be installed on a system. Even more: a developer may choose and purchase one of them and stick with it, but some application or demo might install another driver and if there's a conflict in the file names or in the registration names, the bizarre behavior a posteriori wouldn't be easily explainable by a developer not aware that a new driver overwrote some setting in the registry or some DLL in the system32 directory. Personally, I've used the manual installations of two ODBC drivers and two OLE/DB providers for IB, looking for the best alternative in the project I'm developing. Thanks to God, no clashes yet, but I war near due to some similar names.

All I've written was with NT4 in mind, but W9X and W2K are not different in essence, so the same precautions are welcome on all flavors of MS operating systems. Take care, please and you will be doing a favor to prospective clients and avoiding unnecessary support calls at the same time. Remember, IB market is not well known, so you may not be aware of competing efforts in the same topic.

Having said all I wanted to say above, I present in a more readable form the current information I have about IB drivers.

The URLs to download these drivers are located in the section packages and utilities of this site. Please contact me if you want to be listed or if you want to do some correction.

This page was last updated on 2000-12-31 03:53:36