How To Have Your ODBC Jet 3.5 and 4.0 Applications Co-exist

When you install MDAC 2.1 or later, Microsoft Office 2000, or Microsoft Visual Studio 6 SP3, it upgrades the ODBC drivers for Jet from version 3.5 to version 4.0. Existing applications use the new drivers automatically and this may cause some applications to fail if they require functionality that the new ODBC drivers does not support. This article provides two methods to allow your ODBC applications that require Jet 3.5 and Jet 4.0 to co-exist.

Microsoft provides this article for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose. This article assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures.

The steps described should only be used if you are an experienced programmer. Modification to the Windows Registry may cause some applications or the operating system to change behavior or stop working. Make a backup of the registry before attempting any modifications.

Upgrading your Microsoft Access ODBC driver from version 3.5 to version 4.0 provides your applications a number of benefits, including the ability to read and write Jet 4.0 format MDB files. However, if your application uses the IISAM drivers, some functionality is lost, which could result in your application not working.

For new application development, note the following loss of functionality and respective workarounds with the Jet 4.0 ODBC Driver:

• The FoxPro IISAM driver is no longer supported. Instead, use the Visual FoxPro ODBC driver. The driver is more capable than the IISAM driver, though you have to give up use of the Seek method.
• The dBase and Paradox IISAMS are now restricted to allow read-only access to these type of files. However, the dBase and Paradox IISAMs do allow updates if the Borland Database Engine (BDE) is installed. The BDE must be licensed from Inprise.

For existing applications, you can replace the version 4.0 ODBC drivers with the version 3.5 drivers.

For additional information, click the article number below to view the article in the Microsoft Knowledge Base: However, this method prevents applications requiring the version 4.0 ODBC driver from working correctly. It is also susceptible to having the ODBC driver upgraded the next time an MDAC or other application is installed.

The methods described below allow your ODBC applications that use Jet 3.5 and Jet 4.0 to co-exist and run simultaneously on the same computer. It assumes that Jet 3.5 and Jet 4.0 are both installed on the computer and the default ODBC driver, as shown in ODBC Administrator, is version 4.0. If you need to install Jet 3.5 on the computer, you can install any DAO 3.5 application that uses the appropriate IISAM drivers or you can copy and register the files outlined in the following Knowledge Base article: The following two methods describe how the Jet 3.5 and Jet 4.0 ODBC Drivers to co-exist. The first method works with any 32-bit version of Microsoft Windows, but requires the application to use a DSN to make the connection. The second method works regardless of whether the application uses a DSN or makes a DSN-less connection, but can only be implemented on either Microsoft Windows 98 Second Edition or Microsoft Windows 2000.

The DSN Method

When making an ODBC connection through a DSN, the ODBC driver manager uses the path to the driver as stored in the Windows Registry for the DSN. Normally, this points to the default version of the ODBC driver. However, you can override this and make the DSN point to a copy of the ODBC driver in your application directory, or if the DSN is used by more than one application, in some other standard location. The registry key for a System DSN is:
The registry key for a User DSN is:
Where dsn-name is the name of the DSN. Alter the Driver value to point to the directory where the alternate driver is located. You will also need to copy the following files to the target directory:

The LOCAL File Method

Microsoft Windows 98 Second Edition and Microsoft Windows 2000 introduce a new feature for redirecting COM and LoadLibrary calls. This feature overrides the specified path and causes the DLL or OCX to be loaded from the application directory. To implement the LOCAL File Method, complete the following steps:

1. Install the files listed in the previous section in the application directory.
2. Install a dummy file in the application directory. The dummy file must have the same file name as the application file and have following file extension: .exe.local. For example, if your application is Project1.exe, the dummy file should be called Project1.exe.local. If you have more than one EXE file, you will need a dummy file for each.

This causes the operating system to load the DLLs from the application directory, regardless of whether a DSN or DSN-less connection is made.

Notes for "The LOCAL File Method":

1. If a COM component is not located in the application directory, it will be loaded from the specified path. Non-COM DLLs (other than system DLLs) must reside in the application directory or a run-time error occurs. If your application uses other non-COM DLLs, you may have to redistribute them in the application directory instead of having them copied into the system directory.
2. When running the application in the Visual Basic IDE, it is best to have the current version of the ODBC drivers installed in the default location. Otherwise, you would have to add a VB6.exe.local file in the Microsoft Visual Basic directory and copy the DLLs into that directory. It might also cause some other undesirable side-effects.