MDAC 2.5 SDK - Technical Articles
Microsoft's data access technology before 1996 consisted of several technologies, including the Open Database Connectivity (ODBC) library and software development kit (SDK), and the Data Access Objects (DAO) library. In 1996, two major new data access technologies, OLE DB and Microsoft® ActiveX® Data Objects (ADO) were released. The Active Data Connector, later to become Remote Data Services for ADO, was also released. In 1998, OLE DB for Online Analytical Processing (OLAP) was released.
Each technology is implemented using several dynamic-link Libraries (DLLs). The SDKs through which each technology was released included information on redistributing the DLLs. However, many application vendors and information systems groups installed the redistributable versions of these DLLs in a variety of locations on a workstation, rather than in one consistent location for all workstations. By doing this, they could be sure that the correct version of a DLL was indeed installed on the workstation with the application.
This situation created a problem because of the way Microsoft Windows® (except Microsoft Windows 2000 and Microsoft Windows 98 Second Edition—see below) manages DLLs. Once Windows loads a particular DLL into memory, it is used by all applications that need a DLL with the same name, regardless of the DLL's version. Thus, the wrong version of a DLL was sometimes used even if the right version of the DLL was installed where the setup program put it, causing applications to crash or run incorrectly. This problem was difficult to correct because the exact cause of the problem was difficult to detect.
To illustrate this problem, assume that two versions of a DLL are installed on a workstation in two different folders, as follows:
Now suppose that Program1.exe in D:\DataClient began running and consequently loaded Msador15.dll version 2.0.3002.11 into memory. The module name for this DLL is ADOR15. Later, Program2.exe, in a different folder, begins to run and attempts to load the latest version of Msador15.dll. Windows has the module ADOR15 already in memory. It can't unload the module, and it can't load a different version of Msador.dll in memory. Therefore, it returns a handle to the 2.0.3002.11 version to Program2.exe, which crashes when it calls Msador15.dll because it is expecting the newer version 2.10.3513.2.
To conquer part of this problem, Microsoft collected data access technologies and created a single installation program. The intention was to prevent multiple versions of the same DLL from being installed at different locations on the workstation, as well as making sure that all versions that were installed had been designed and tested to work with each other. This installation program is known as the Microsoft Data Access Components (MDAC) setup program.
Unfortunately, this approach was not consistently applied, which aggravated the problem. Since MDAC was introduced, software installation programs have not uniformly installed the data access technologies in MDAC. Only since mid-1999 has MDAC been uniformly installed, and with the release of Windows 2000, MDAC 2.5 will be part of the operating system, further reducing the likelihood that this problem will occur.
By allowing multiple versions of the same DLL to be loaded at the same time, Windows 2000 and Windows 98 Second Edition eliminate the DLL-version problem entirely. This feature is called side-by-side component sharing. Read the MSDN technical article "Implementing Side-by-Side Component Sharing in Applications" for details on this feature.