An ODBC (DSN/Driver) Manager DLL written in C# (Version - I)

• Download source - 6.16 Kb
• Download DLL - 3.85 Kb

Audience

Programmers who are using ODBC to connect to any database, and wish to program in C#/.NET.

Introduction

Through this article, I want to present readers with an ODBCManager class that allows a user to have a list of ODBC drivers installed in his/her system. Also, this class gives the users all system as well as user DSNs.

Hard Words

(Experienced readers can ignore/skim through this section. I have lifted most of the following stuff from the Internet)

About DSN

DSN is an acronym for Data Source Name. It's a simple and standard way to describe how to connect to a data source (database) using an ODBC driver. More importantly, using a DSN means we can change the location of our data by updating the DSN, no update to our application is required. But we have to keep in mind that DSNs only describe ODBC connections, not OLEDB connections.

There are three types of DSNs; system, user and file.

System DSNs and User DSNs differ only in who can access them on the system. A file DSN, however, is not really a data source. It is a file that contains all the connection parameters used to connect directly to an ODBC driver.

System and user DSNs are Windows registry based, while file DSNs are stored in the file system. We normally create and administer DSNs through the ODBC Data Source Administrator, found in Control Panel on NT/9x machines, or in Administrative Tools for Win2K machines. However, there is nothing magical about editing DSNs. We can use regedit to view/modify user or system DSNs, and Notepad works fine for file DSNs.

Most information about DSNs is stored in the registry.

• HKEY_LOCAL_MACHINE\Software\ODBC\ODBCINST.INI contains a list of all ODBC drivers installed on the machine.
• HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI contains all of the system DSNs stored as separate subkeys.

ODBC.INI has two other subkeys, ODBC Data Sources that contains a list of all system DSNs, and ODBC FileDSN, which contains the name of the folder where file DSNs are stored (C:\Program Files\Common Files\ODBC\Data Sources is the default). User DSNs are stored in HKEY_CURRENT_USER\Software\ODBC\ODBC.INI.

Choosing which type of DSN to use, depends on how our application works. In almost all cases, a system DSN works. If we use a user DSN, then we'll have to do some extra work to make sure the DSN gets created when a user new to that machine logs in for the first time.

About ODBC Driver

An ODBC driver acts as a “translator” between an application and a database. There are drivers available for many databases like Oracle, MS Access, SQL Server, Foxbase etc. Main use of these drivers is, without having a client program supplied by the vendor of the data base, these drivers allow us to interact with databases. For example, let us suppose we have an Oracle database which has some tables in it. Now, if we have an Oracle ODBC driver installed in our machine, then we don't need to have the Oracle S/W (Expensive) to talk with that database. But we have to write our own routines to talk to the database using ODBC provided by C++/C# or whatever language we want to use (That supports ODBC Driver API).

How this class works

ODBCManager class is defined in ODBCMngr namespace. This class is present in the DLL ODBCMngr.DLL. This class has all static methods. So no instance needs to be created (Infact users can't create one, since the class is following singleton pattern). Apart from the ODBCManager, the DLL has two other classes: ODBCDriver and ODBCDSN.

This ODBCManager class has the following static methods.

1. public static ODBCDriver[] GetODBCDrivers();
2. public static ODBCDriver GetODBCDriver(string driverName);
3. public static ODBCDSN[] GetSystemDSNList();
4. public static ODBCDSN GetSystemDSN(string dsnName);
5. public static ODBCDSN[] GetUserDSNList();
6. public static ODBCDSN GetUserDSN(string dsnName);
7. public static RegistryKey OpenComplexSubKey(RegistryKey baseKey, string complexKeyStr, bool writable);

Except for method 7, the signatures of the above methods are self explanatory.

I added method 7 to the class, since I don't find any method in the .NET framework Registry class that gives a RegistryKey for a nested key. For example, to get the Software subfolder in HKEY_LOCAL_MACHINE root folder of the registry, the following method call can be used.

RegistryKey fianlKey = (Registry.LocalMachine).OpenSubKey("Software");

Now if we want the key for Software\ODBC\ in HKEY_LOCAL_MACHINE root folder of the registry, the following method calls can be used.

RegistryKey fianlKey = (Registry.LocalMachine).OpenSubKey("Software");
fianlKey = fianlKey.OpenSubKey("ODBC");

Now my method (7) can eliminate multiple calls to OpenSubKey() method as done above. So using (7):

RegistryKey finalKey = 
  ODBCManager.OpenComplexSubKey(Registry.LocalMachine, 
  "Software\ODBC\", false);

Note: Last parameter is a boolean flag that tells the OpenComplexSubKey method to create a sub folder if it is not present.

Program Notes

Since this is a DLL that has methods we can call, I don't really see the use of writing a client program. So I am not writing any program using the above DLL.

Please note that this is version - I of the DLL. I will try to add more related stuff to this DLL in future. If I do so, I will update again.

I hope I explained all the things that are needed to be explained. If any one of you feel I did some thing terribly wrong or not clear, please let me know. I will try to correct and/or respond.