Redistributing Microsoft Data Access Components

Don Willits
Microsoft Data Access Group

July 1998

Summary: Explains the issues involved with redistributing MDAC components. (22 printed pages) Discusses:

• Defining Microsoft Universal Data Access Strategy, Microsoft Data Access Components, and the Data Access _.
  
  
• Redistributing MDAC (including dependencies and file lists).
  
  
• Redistribution with various development environments.
  
  
• Pros and cons of using the redistribution provided by Microsoft.

Introduction

The Microsoft® Data Access Components (MDAC) are at the edge of what has come to be known as "DLL hell." There are two reasons for this. First, a large number of applications redistribute one or more MDAC components, including Open Database Connectivity (ODBC), OLE DB, Microsoft ActiveX® Data Objects (ADO), and the Remote Data Service (RDS). And second, MDAC components have direct and indirect dependencies on other redistributable system components. This article is a comprehensive overview of the issues associated with redistributing MDAC components for recent releases. It enumerates the issues you must address when installing or redistributing MDAC components.

MDAC redistribution has generated several Microsoft Knowledge Base articles. Rather than repeating the content of those articles, this article provides references to them, and context to help the reader decide whether further details are needed.

Microsoft Universal Data Access Strategy, Microsoft Data Access Components, and the Data Access SDK

Universal Data Access is the Microsoft strategy for providing high-performance access to all types of information (including relational and nonrelational data) across an organization, from the desktop to enterprise systems. It accomplishes this with four key technologies: ODBC, OLE DB, ADO, and RDS. Recently, online analytical processing (OLAP), or multidimensional extensions have been added to both OLE DB (OLE DB for OLAP) and ADO (ADO MD).

ODBC is an international standard for manipulating relational data by using SQL query syntax across disparate data sources. Because it is an international standard, you can use it to manipulate a vast array of relational data sources by using numerous ODBC drivers from Microsoft and third-party vendors. The key disadvantage of ODBC is that it is limited to relational, SQL syntax–based data.

OLE DB is the strategic low-level interface to data across the organization from Microsoft. OLE DB is an open specification. It builds on the success of ODBC by providing an open standard for accessing all kinds of data. OLE DB imposes no specific limitation on either the query syntax or the structure of the data exposed as long as it can be retrieved in tabular form. An OLE DB data provider is analogous to an ODBC driver: It exposes a data source to an OLE DB consumer, such as ADO. An increasing variety of OLE DB data providers are being released by Microsoft and third-party vendors. The first OLE DB data provider, the Microsoft OLE DB Provider for ODBC Drivers, enables you to expose any ODBC data source to an OLE DB consumer.

Microsoft ADO is the strategic, language-neutral, high-level interface to data exposed by OLE DB. ADO provides consistent, high-performance access to data, whether you are creating a front-end database client or middle-tier business object by using an application, tool, language, or even an Internet browser. ADO is the single data interface you need to know for 1 to n–tier client/server and Web-based data-driven solution development. Although you could write your consumer application directly to an OLE DB provider by using C++, ADO is the definitive OLE DB consumer.

You can use the Microsoft Remote Data Service to remote an ADO recordset across one of three protocols (HTTP, HTTPS, or DCOM). RDS was originally intended for Web-based clients, but you can implement your RDS client in any development environment or language. You can optionally implement a server-side business object for generating and receiving a recordset, or you can use the default business object that RDS provides with its server-side components. You are required to use Microsoft Internet Information Server (IIS) to host the RDS server components only if you use the HTTP or HTTPS protocol. Using DCOM to marshal objects (recordset or otherwise) with RDS eliminates the IIS dependency. RDS provides the advantages of client-side caching of data results, updatable data, and support for some data-aware ActiveX controls.

The Microsoft Data Access Components include these four technologies as well as ODBC drivers and OLE DB data providers. Starting with version 1.5, MDAC has included extensions to both OLE DB and ADO, most notably (but not limited to) online analytical processing, or multidimensional data. Of the three significant releases of MDAC components, only one was publicly known as MDAC. MDAC 1.0 did not ship as a coordinated, stand-alone program, but was included with various software development kits (SDKs) and products. MDAC 1.5, which did feature a complete, stand-alone installation, was also included with various SDKs and products. With version 2.0, MDAC was renamed to the Microsoft Data Access SDK, and both the ODBC SDK and OLE DB SDK were rolled into it. Now, the MDAC 2.0 components are considered to be the run-time (non-SDK) elements of the Data Access 2.0 SDK.

For the sake of clarity, this article refers to the MDAC stack as a specific collection of ODBC, OLE DB, ADO, and RDS run-time components. For example, the MDAC 1.0 stack contained ODBC 3.0, OLE DB 1.1, ADO 1.0, and the Advanced Data Connector (ADC) 1.0. (The Advanced Data Connector was the immediate precursor to the Remote Data Service released in MDAC 1.5). The MDAC 1.5 stack included ODBC 3.5, OLE DB 1.5, ADO 1.5, and RDS 1.5. The MDAC 2.0 stack includes ODBC 3.51, OLE DB 2.0, ADO 2.0, RDS 2.0, OLE DB for OLAP, and ADO MD.

This article refers to MDAC redistribution as the mechanism that installs just the run-time components for a given MDAC stack. Anything else—which includes the ODBC 3.x SDK, OLE DB 1.x SDK, and the MDAC stand-alone Setup—contains a superset of the redistribution, adding samples, documentation, headers and LIBs, and so forth. You use an MDAC redistribution with the installation used to distribute your application to customers. You use the MDAC or SDK Setups to install on your development machine to create those applications in the first place. This distinction is especially important to remember when we discuss MDAC 1.5 Setup and redistribution scenarios.

Universal Data Access, the Microsoft Data Access Components, the Data Access SDK, the ODBC SDK, and the OLE DB SDK—All of these are different faces for the same thing: Microsoft database strategy.

MDAC Redistribution and Dependencies

This section enumerates the requirements for redistributing MDAC 1.x or 2.0 and other components. A discussion of redistributing MDAC components would be incomplete without also discussing dependencies for MDAC components, and in some cases, the Setup program used to install MDAC. Integration of MDAC redistribution with the redistribution mechanisms of various Microsoft development products will be discussed in "Redistribution with Various Development Environments," later in this article.

MDAC components consist of a matched set of dynamic-link libraries (DLLs). It is not enough to simply install Msado15.dll, for example, for ADO to work correctly. You need the complete set of ADO DLLs, as well as an underlying OLE DB provider (which usually has one DLL plus a set of helper DLLs) and ODBC.

As more native OLE DB providers are released—that is, providers that do not use ODBC to expose the data source—the need for ODBC will diminish for ADO-based applications. However, ODBC continues to be used widely in the industry. Failing to install a complete set of DLLs for a specific MDAC technology is a common customer issue. If you do not include a complete set, and do not acknowledge the dependencies between MDAC technologies, you decrease your chances to successfully redistribute your application.

The MDAC 1.0 Stack

MDAC 1.0 was a precursor of the coordinated, stand-alone Setup, MDAC of today. MDAC 1.0 components included ODBC 3.0, OLE DB 1.1, ADO 1.0, and the Advanced Data Connector (ADC) 1.0. ADC 1.0 used a subset of the ADO recordset; it was independent of ADO. Previously, ODBC existed pretty much on its own, although the OLE DB 1.0 SDK released in August of 1996 began to point the way toward MDAC. Later in 1996, the MDAC 1.0 stack was released through a variety of distribution mechanisms, but centralized or coordinated MDAC did not arrive until version 1.5.

ODBC 3.0 shipped with the ODBC 3.0 SDK (available at the time by Web download), as well as Internet Information Server 3.0 and the OLE DB 1.1 SDK. OLE DB 1.1 and ADO 1.0 shipped with the OLE DB 1.1 SDK (available with Microsoft Visual Studio™ 97 or, at the time, by Web download), and with Internet Information Server 3.0. The Advanced Data Connector shipped with Internet Information Server 3.0, as well as being available (at the time) on the Web as a downloadable .cab file.

MDAC 1.0 included ODBC drivers for Microsoft Access/Microsoft Jet, SQL Server™, and for the first time, a Microsoft ODBC driver to expose Oracle data. The Microsoft OLE DB Provider for ODBC Drivers was the first and only OLE DB provider released with MDAC 1.0.

In Visual Studio 97, individual products installed different versions of ODBC (and with it potentially OLE DB and ADO). Microsoft Visual Interdev™, for example, included Active Server Pages (ASP), the component of Internet Information Server 3.0 that installed ODBC 3.0, OLE DB 1.1, and ADO/ADC 1.0. However, Microsoft Visual Basic® 5.0 installed ODBC version 2.65 and no OLE DB or ADO components. Microsoft Visual C++® 5.0 installed ODBC 2.65; however, Visual C++ installation options for Visual Studio 97 included the option to install the OLE DB 1.5 SDK, which provided the entire MDAC 1.0 stack.

In general, it is safe to mix and match ODBC drivers with ODBC Driver Manager/Core Components. You should make sure the ODBC Driver Manager is more recent than the ODBC drivers (although the product group attempts to ensure that the ODBC Driver Manager and Microsoft ODBC drivers are backwardly compatible).

Redistribution of ODBC 3.0 was not intuitive. The assumption was that the developer using ODBC would also be responsible for redistributing it. To help customers accomplish this goal, Microsoft Technical Support created a sample. This sample, although unsupported, helped to address customer needs for an ODBC Setup. The sample, a fully functional ODBC 3.0 installation mechanism, comprises a thin wrapper built on top of the Setup application programming interface (API) included with the Microsoft Platform SDK. (See Knowledge Base article Q174191 [SAMPLE: ODBC 3.0 Installation].) By tweaking the .inf file used by the sample, customers could expand the sample to install their entire application.

Redistribution of OLE DB and ADO for MDAC 1.0 was, initially, a complicated process. For MDAC 1.0, if you distributed either OLE DB or ADO, you needed to distribute the other. A Knowledge Base article by Don Willits lists the core OLE DB and ADO components to use for building an MDAC 1.0 redistribution. (See Knowledge Base article Q168122 [HOWTO: Redistributing ADO 1.0 or ADO/R 1.0 with OLE/DB 1.1].) But the solution presented in this article forced the end developer to do too much work to actually implement ADO and OLE DB redistribution.

In the summer of 1997, the product group provided a signed, stand-alone Setup that installed both ADO 1.0 and OLE DB 1.1, along with an ADO 1.0 fix. (The ADO 1.0 GetChunk method, when working with a double-byte character set and returning binary large object (BLOB) data, returned the length of the data in bytes rather than characters.) This fix gave developers a solution equivalent to the contents of Q168122. It was released on the Web and documented in Knowledge Base articles. (See Q173611 [FIX: ADO GetChunk Method Breaks Blob Data for DBCS] and Q173487 [INFO: ADO 1.1 QFE Download Now Available (Updates ADO 1.0)].)

Note   A QFE is a Microsoft term for quick fix engineering—a "hot fix."

ADO 1.0 required a license key in the registry to run. This was not well documented. Microsoft Technical Support created a sample DLL that, when registered, added the license key to the registry. (See Knowledge Base article Q172394 [FILE: Adoreg.exe License Key Registration DLL and ADO Use Tips].) With ADO 1.5, the need for a license key was removed.

Redistribution of ADC 1.0, and later 1.1 components, was accomplished by a .cab file installation. However, in some scenarios it was impossible to upgrade from ADC 1.0 to 1.1 because of registry problems with the .cab files. A tester for the Microsoft Data Access Group (which creates MDAC) created a utility, ClsidView, that helped to resolve these problems. The utility was released as a sample in a Knowledge Base article. (See Q176562 [FILE: Clsidvw.exe OLE/Createable Objects Registry Diagnostic].)

The ClsidView diagnostic is an invaluable tool, not just for resolving early ADC 1.0/1.1 installation difficulties, but for verifying the correct installation of any of the MDAC releases (1.0, 1.5, and 2.0). ClsidView is similar to the OLE COM Object Viewer, except that it views collections of DLLs that comprise an entire technology. By editing an .ini file, you can easily modify ClsidView to manage any given technology that ships as a collection of DLLs.

ODBC 3.0 was tested and supported on Microsoft Windows NT® 3.51 and 4.0 and on Microsoft Windows® 95. OLE DB 1.1, ADO 1.0, and ADC 1.0 each were tested and supported on Windows NT 4.0 and Windows 95; however, each had dependencies that prevented them from being supported or tested on Windows NT 3.51.

The only ODBC driver installed by the ODBC 3.0 SDK was the SQL Server Driver. ODBC drivers for Microsoft Access or Oracle were available only as part of Microsoft development products such as Visual Basic, Visual C++, or Microsoft Access 97.

At the time, the only MDAC dependencies were internal to MDAC. The only OLE DB provider available exposed ODBC data sources, requiring that any OLE DB consumer (whether it was an OLE DB or ADO application) also required ODBC. The Setup programs for the MDAC 1.0 stack were either self-contained—such as Active Server Pages or the OLE DB SDK—or required a developer to implement their own redistribution mechanism (as documented in Knowledge Base article Q168122). With MDAC 1.5, this all changed.

Table 1. File Locations and Distribution for MDAC 1.0 Components

SYS\…<Drive>:\<Windir>\<Systemdir>

OLE\…<Drive>:\Program Files\Common Files\System\Oledb

ADO\…<Drive>:\Program Files\Common Files\System\Ado

RDS\…<Drive>:\Program Files\Common Files\System\Msadc

The MDAC 1.5 Stack

With MDAC 1.5, more coordination was brought to both the Setup of MDAC components and redistribution. MDAC 1.5 consisted of ODBC 3.5, OLE DB 1.5, ADO 1.5, and the Remote Data Service 1.5. The Remote Data Service is the successor to the Advanced Data Connector, but was renamed to reflect that it is increasingly a feature of ADO. With MDAC 2.0, the documentation for RDS is included in the same location as for ADO.

Once again, portions of MDAC 1.5 were included with various SDKs and products. MDAC 1.5 was released on the Web as a stand-alone Setup, as well as within the Windows NT 4.0 Option Pack. Portions of MDAC 1.5 were included in Internet Explorer 4.x, specifically the RDS client components. Windows 98 includes MDAC 1.5 components, and both the OLE DB 1.5 SDK and ODBC 3.5 SDK contain MDAC 1.5 components.

MDAC 1.5 included ODBC drivers for Microsoft Access/Microsoft Jet, SQL Server, and a significant update to the Microsoft ODBC Driver for Oracle. In addition, two other OLE DB providers were available from Microsoft (although not included with the MDAC stack). OLE DB providers for Microsoft Index Server were available separately from the MDAC stack. Both providers leveraged OLE DB strengths in ways ODBC could not have supported, specifically for using non-SQL query syntax to retrieve data through the OLE DB data provider from a nonrelational data store.

MDAC 1.5 has had five (or more) separate releases, each with different versions of ODBC 3.5, OLE DB 1.5, ADO 1.5, and RDS 1.5 components, as well as ODBC drivers and OLE DB providers. The first two releases, other than file version stamping and bugs fixed in the Setup, had no significant differences. The following list summarizes MDAC 1.5 releases:

• Internet Explorer 4.0: Shipped with Internet Explorer 4.0 and Internet Client SDK 4.0. Integrated within the Setup of both products.
  
  
• MDAC 1.5 (PDC): Updated the components shipping with Internet Exporer. Available only on the 1997 Professional Developers Conference CD within the MDAC stand-alone Setup program.
  
  
• MDAC 1.5a: Available on the Web from October 6 to December 20, 1997 within the MDAC stand-alone Setup program.
  
  
• MDAC 1.5b: Available with the Windows NT 4.0 Option Pack, the MDAC stand-alone was actually integrated within the Option Pack (and not as a separate Setup).
  
  
• MDAC 1.5c: Available on the Web after December 20, 1997, both with the MDAC stand-alone and as a smaller MDAC redistribution that just installed the run-time components. MDAC 1.5c also matches bits included with the OLE DB 1.5 and ODBC 3.5 SDKs. The actual bug fixes between 1.5b and 1.5c were incremental but significant, fixing problems with ADO threading and ODBC connection pooling.
  
  
• Windows 98 and/or Internet Explorer 4.01 Service Pack 1: A final 1.5d release of MDAC can be found within Windows 98 and the Internet Explorer 4.01 Service Pack 1. Each product contains an incomplete subset of MDAC components, but both contain the only complete and most current set of ADO and RDS 1.5d components. Windows 98 ships a pre-MDAC subset of the Access ODBC Driver, a subset of the MDAC 1.5a OLE DB Provider for ODBC, and 1.5d components for both ADO and RDS. Internet Explorer 4.01 SP1 ships ODBC 3.0 (MDAC 1.0), pre-MDAC 1.5 Access driver, a single file of the MDAC 1.0 SQL Server ODBC Driver, a subset of the MDAC 1.5a OLE DB Provider for ODBC, and the latest ADO and RDS 1.5d components. To get a complete set of the latest 1.5 components with either Windows 98 or Internet Explorer 4.01 SP1, you must install MDAC 1.5c on top, which will update the out-of-date ODBC and OLE DB components. Because MDAC 1.5d was released by both products so close to the release of MDAC 2.0, the MDAC product group did not release either a stand-alone or redistribution version of the MDAC Setup programs. The single significant change in 1.5d consists of removing the dependency of RDS to mark a DCOM-based business object as safe for scripting and initialization.

Redistribution and dependencies for MDAC 1.5 became both simpler and more complex. It was simple to use the MDAC 1.5 stand-alone Setup to install the entire MDAC 1.5 stack, even though the Setup program itself was operating system–dependent: The MDAC stand-alone for Windows 95 could not be run on Windows NT, and vice versa. MDAC 1.5 also provided a rich feature set for installing specific components or drivers/providers from the command line. MDAC 1.5 redistribution provided an operating system–independent Setup that ran equally well on Windows NT 3.51 and 4.0, as well as Windows 95. For details on using MDAC 1.5 redistribution, see Knowledge Base article Q181126 [INFO: Redistribution for MDAC 1.5 Components Available].

The MDAC redistribution did not have as many of the options for configuration that developers wanted as the MDAC stand-alone. However, the MDAC stand-alone didn't always deliver what developers thought they were asking for: The MDAC stand-alone was capable of detecting what was required to install a given component, even if the command-line switches used to invoke it did not. There are some good reasons not to use the MDAC stand-alone to install MDAC components in a redistribution scenario. For details, see Knowledge Base article Q177913 [Use the MDAC Stand-alone Setup EXE in Unattended Mode].

You should use the MDAC redistribution to redistribute the 1.5 stack. The MDAC stand-alone appears to give more options for installing specific components. However, it is operating system–dependent, which increases the size and complexity of your redistribution mechanism. That is, you have to ship two 6-MB files, one for Windows NT and one for Windows 95. Also, your redistribution mechanism must be able to detect which operating system it is currently running on so that it can invoke the correct version of the MDAC stand-alone.

The MDAC stand-alone Setup really comprised half an SDK, providing SDK elements for the MDAC 1.5 stack. However, two other SDKs—the ODBC 3.5 SDK (released in Spring of 1998) and the OLE DB 1.5 SDK (released in Fall of 1997)—complemented the MDAC Setup. If you installed all three Setups, you had a complete set of samples, documentation, headers, and LIBs for the MDAC 1.5 stack. This is, as much as anything, the reason the Data Access SDK was created: Developers only have to install one Setup to get the entire SDK for MDAC 2.0.

The MDAC 1.5 stack had a dependency on an OLE Automation patch, especially when running on older versions of Windows 95. (For instructions for obtaining this patch, see Knowledge Base article Q164529 [FILE: Updated Automation System Files].) Further, the MDAC 1.5 stand-alone had a dependency for an updated Comctl32.dll available with Internet Explorer 3.02 (or later), as well as within a stand-alone patch. (For instructions on obtaining the Comctl32.dll patch, see Knowledge Base article Q165487 [Incorrect or Garbled Text on Tab Labels in Properties].) Without the updated Comctl32.dll, the MDAC stand-alone Setup dialog box was approximately 20 times wider than the width of the display. (For documentation, see Knowledge Base article Q183092 [PRB: MDAC Stand-alone Setup Dialog Overly Large on Windows 95].) If you dragged the dialog box far enough to the left and clicked Next, the stand-alone Setup would then be stopped. The MDAC redistribution did not suffer from this Comctl32.dll dependency or misbehavior if the DLL was not present.

These dependencies were not well understood when MDAC 1.5 was released. The Universal Data Access Web page incorrectly stated that you had to install Internet Explorer 4.0 before installing MDAC 1.5. In fact, Internet Explorer 4.0 happened to install the Automation and Comctl32.dll patches; but you could obtain both patches separately and independent of Internet Explorer 4.0 by using the articles referenced in the previous paragraph. You do not need Internet Explorer 4.0 to develop and redistribute MDAC 1.5–based applications.

The only actual dependency on Internet Explorer 4.0 existed with the Remote Data Service, in particular if your RDS client application was Web based. Otherwise, you could develop an MDAC 1.5 application independent of having Internet Explorer installed on your machine. To redistribute an RDS client application, there is a specific set of minimum necessary DLLs, whether your client is based on Visual Basic or not. For details, see the Knowledge Base article Q176874 [HOWTO: Distributing RDS Client with Visual Basic Setup Wizard].

With MDAC 1.5, an increased dependency was introduced between ODBC 3.5 and the OLE DB Provider for ODBC Drivers. Version 1.1 of the OLE DB Provider for ODBC was written to specific Unicode specifications within ODBC 3.0. Because these specifications have changed in ODBC 3.5, you must have version 1.5 of the OLE DB Provider for ODBC when redistributing an ODBC 3.5–based application. Otherwise, the installation of your software risks breaking existing OLE DB and ADO–based applications on your customers' machines. This dependency is documented in Knowledge Base articles Q178852 [INFO: OLE DB Provider for ODBC Now an ODBC 3.5 Core Component] and Q178843 [FILE: Required Files to Redistribute ODBC Version 3.5].

An occasional point of confusion among developers is the minimum requirements to redistribute an RDS client. If your RDS 1.5 client is indeed Web-based, then, yes, you do need Internet Explorer 4.0. (If you made your Web client using RDS 1.1, you can use Internet Explorer 3.02.) If your client is not Web-based, you do not need to install Internet Explorer. For the minimum requirements needed to install RDS client components, see Knowledge Base article Q176874 [HOWTO: Distributing RDS Client with Visual Basic Setup Wizard]. (The article is written in the context of the Visual Basic Setup Wizard, but the requirements are valid in other contexts.)

The Msadc11.cab file that originally shipped with all five releases of MDAC 1.5 did not properly take advantage of file versioning. Specifically, it would not correctly update and overwrite a system that had ADC 1.0 components already installed. Therefore, clients with older RDS client components would not download the newer components in Msadc11.cab. The ClsidView sample addressed this problem. However, the product group recently released an updated version of Msadc11.cab that corrects these problems in both MDAC 1.5 and MDAC 2.0 (See Knowledge Base article Q185963 [FIX: Updated RDS Msadc11.cab for Internet Explorer Download PRB] for a discussion of the problem and how to obtain the updated Msadc11.cab.) There is no RDS .cab file for RDS 1.5 components. The only way to install them is by using Internet Explorer 4.01, the MDAC stand-alone Setup, or the MDAC redistribution.

MDAC 1.5 redistribution is useful, but there are times when a .cab file that installs MDAC 1.5 components would be even better. To learn how to build a .cab file around the MDAC 1.5 redistribution, see Knowledge Base article Q185622 (HOWTO: Adding the MDAC Redistribution Setup to CAB Files).

Many developers want to control the size of their distribution. The bulk of MDAC 1.5 redistribution components is not in ADO, RDS, or OLE DB, but in ODBC or in various ODBC drivers. The Access driver itself consumes nearly 2 MB. This is why the MDAC redistribution comes in two flavors, Mdacrdst.exe and Mdacfull.exe. Mdacrdst (1.7 MB) contains ODBC 3.5, the OLE DB Provider for ODBC Drivers, ADO 1.5, RDS 1.5, and just the SQL Server ODBC Driver. Mdacfull (nearly 4 MB) has all the components included in Mdacrdst, plus the Oracle and Microsoft Access/Microsoft Jet ODBC drivers.

Windows 98 and Internet Explorer 4.01 do contain the elements of MDAC 1.5d. However, their versions of ODBC and OLE DB are incomplete and older than those in MDAC 1.5c. To ensure that you have the latest bits, apply Windows 98 or Internet Explorer 4.01 Service Pack 1, and then install MDAC 1.5c. The changes for MDAC 1.5d were incremental; they are of benefit only if you use the Remote Data Service, and then only if you marshal by using the DCOM protocol.

ODBC 3.5 was tested and supported on Windows NT 3.51 and 4.0 and Windows 95. OLE DB 1.5, ADO 1.5, and RDS 1.5 were tested and supported on Windows NT 4.0 and Windows 95. However, once again, dependencies prevented these three components from being supported or tested on Windows NT 3.51.

Table 2. File Locations & Distribution for MDAC 1.5 Components

SYS\…<Drive>:\<Windir>\<Systemdir>

OLE\…<Drive>:\Program Files\Common Files\System\Oledb

ADO\…<Drive>:\Program Files\Common Files\System\Ado

RDS\…<Drive>:\Program Files\Common Files\System\Msadc

The MDAC 2.0 Stack

MDAC 2.0, the latest release, is distributed within the Data Access 2.0 SDK. The Data Access SDK 2.0 combines and updates the contents of MDAC 1.5, the ODBC 3.5 SDK, the OLE DB 1.5 SDK, and the OLE DB for OLAP specification. The Data Access SDK combines all of the run-time components, documentation, samples, and also provides an integrated redistribution in the <Drive>:\Msdasdk\Redist directory. Previously, the MDAC 1.5 stand-alone and redistribution shipped separately, occasionally creating confusion as to which one was which. However, the Data Access SDK is completely self-contained and integrated. Also, the 40-MB SDK is easier to distinguish from the 7.9-MB MDAC 2.0 redistribution.

The MDAC 2.0 redistribution comes in one flavor, and installs all of the MDAC 2.0 components as well as ODBC drivers and OLE DB providers for Microsoft Access/Microsoft Jet, Oracle, and SQL Server. The Microsoft Visual FoxPro® ODBC Driver is also included in the redistribution. Previously, this driver was available only by Web download.

The one MDAC 2.0 component dependency that is not handled by the MDAC 2.0 redistribution is the need for DCOM 95 components. OLE DB 2.0 uses definitions found in an update to Ole32.dll that is available in the DCOM95 patch. Like MDAC, Ole32.dll is one DLL of several comprising a specific technology. Simply installing the new version of this DLL does not guarantee MDAC 2.0 will work, because OLE itself will not work if you install only Ole32.dll. You must apply the entire DCOM95 patch, available from this Web site: www.microsoft.com/cominfo/dcom95/. The MDAC redistribution detects when DCOM95 is not installed on your machine; in this case, a dialog box instructs the user to install DCOM95.

The MDAC 2.0 redistribution will install three .cab files on your target machine: Mdac11.cab, Mdac20.cab, and Mdac20_a.cab. Msadc11.cab is for older versions of Internet Explorer and Web-based applications that need RDS 1.1 client components (which will work with RDS 2.0 server components, just as they did for 1.5). Mdac20.cab and Mdac20_a.cab provide RDS 2.0 client components for, respectively, Intel® and Alpha platforms.

The Data Access SDK is released for the Intel platform, but contains an Alpha platform flavor for both the MDAC 2.0 redistribution and the RDS 2.0 client components .cab file.

MDAC 2.0 redistribution is useful, but in some situations a .cab file that installs MDAC 2.0 components would be even better. To learn how to build a .cab file around the 2.0 redistribution, see Knowledge Base article Q185622 (HOWTO: Adding the MDAC redistribution Setup to CAB Files). The article was written for MDAC 1.5, but its information still works.

ADO MD and the underlying OLAP provider, Microsoft PivotTable® Service, is an exception to the MDAC 2.0 redistribution story. ADO MD, the high-level object model for exposing multidimensional data, is contained in a single DLL (Msadomd.dll) and is easily redistributable. However, the PivotTable Service shipping with the Data Access SDK is a beta technology, and not intended for production systems at this time.

ODBC 3.51 was tested and supported on Windows NT 3.51 and 4.0 and on Windows 95. OLE DB 2.0, ADO 2.0, and RDS 2.0 were tested and supported on Windows NT 4.0 and Windows 95. However, dependencies in these three components prevented them from being supported or tested on Windows NT 3.51.

The following table lists run-time MDAC components (as well as other run-time components) installed by both the Data Access SDK and the MDAC 2.0 redistribution.

Table 3. File Locations and Distribution for MDAC 2.0 Components

SYS\…<Drive>:\<Windir>\<Systemdir>

OLE\…<Drive>:\Program Files\Common Files\System\Oledb

ADO\…<Drive>:\Program Files\Common Files\System\Ado

RDS\…<Drive>:\Program Files\Common Files\System\Msadc

Redistribution with Various Development Environments

Previous sections in this article have enumerated the redistribution options and dependencies. The following sections look at what it takes to redistribute MDAC versions with applications built with various Microsoft development products.

Microsoft Visual Basic

For Microsoft Visual Basic 5.0 developers, MDAC redistribution was difficult. The Visual Basic Setup Wizard could not install MDAC 1.0 components. Because of limitations in the Setup Wizard as well as the required installation locations for OLE DB, it was impossible to just add a list of DLLs and let the Setup Wizard work. A sample, Adoregex.dll, was created to compensate for this. (For documentation, see the Knowledge Base article Q172406 [FILE: ADOREGEX.EXE: Components to Redistribute ADO 1.0/1.1].) There were two versions of Adoregex.dll: The first was released prior to the ADO 1.1 QFE, and provided a rudimentary (and not very robust) mechanism to physically install both OLE DB and ADO. (No provision was made for ODBC.) After ADO version 1.1 was released, Adoregex.dll was modified to simply spawn the .exe file that installed the QFE (as well as the full OLE DB 1.1 and ADO 1.1 distribution).

With the release of the MDAC 1.5 redistribution, a new article was published that contained a modification of the source code for the project generated by the Setup Wizard. (For documentation, see the Knowledge Base article Q184265 [HOWTO: Redistribute MDAC 1.5 Components with VB5 Apps].)

For developers redistributing the Remote Data Service, no modifications to the Visual Basic Setup Wizard are required. You simply add a list of the RDS 1.5 client DLLs to the Visual Basic Setup Wizard, and then generate your distribution normally. (For documentation, see the Knowledge Base article Q176874 [HOWTO: Distributing RDS Client with Visual Basic Setup Wizard].)

InstallShield

The most common technique for Microsoft Visual C++ developers is to use InstallShield. However, the version of InstallShield that ships with Visual C++ 5.0 does not support registering DLLs or calling .exe files. Developers redistributing MDAC-based C++ applications need to upgrade to the full version of InstallShield, or to acquire another third-party distribution product that either can call the MDAC 1.5 redistribution or can install DLLs into a specific path. This last point is critical: Because of the way in which OLE DB DLLs are dependent upon each other, if the installing program does not change directory to the location of the DLL when registering it, registration may fail.

Web-Based (Java/Scripting)

Next to the Visual Basic Setup Wizard, Web-based application developers writing applications such as client-side scripts or Java applications require the MDAC stack. For information on how to transform the MDAC redistribution (or any self-contained .exe file that installs a component or technology) into a .cab file, see the Knowledge Base article Q185622 (HOWTO: Adding the MDAC Redistribution Setup to CAB Files).

Office-Based Applications

You can use the Setup Wizard included in the Microsoft Office 97 Developer Edition (ODE) to include and run the MDAC redistribution Setup program. Running the MDAC redistribution program installs MDAC components to other computers. You must add the MDAC redistribution file to your application, and then you can run it automatically by using the options provided in the ODE Setup Wizard.

Redistribution with Client/Server, Three-Tier, OCX, and Active Documents

For traditional client/server applications, you use the MDAC redistribution to install the MDAC stack. The trick is to ensure that the redistribution is invoked by or within whatever Setup mechanism you use to install other run-time system components, as well as your actual application.

Complexity increases when redistribution is considered in the context of a three-tier application. Three-tier applications separate the systems and subsystems of a traditional client/server application into three or more tiers, as follows:

• Presentation tier: This is the user interface, which acts as a client to the business tier. The presentation tier can consist of a traditional executable file (with forms, menus, and so forth), an HTML page, a spreadsheet, a word processor, or some other application.
  
  
• Business tier: This tier is composed of the business objects, all working together to implement the functionality required for the application. Business tier objects can be ASP scripts executed on Internet Information Server, or compiled DLLs and executable files, which are instantiated through Microsoft Transaction Server (MTS) and Distributed Component Object Model (DCOM), or any combination of the above.
  
  
• Data services tier: This tier provides the business tier with the data it needs to function. The data services tier handles the storage and retrieval of data for the application. This data can be stored in a relational database management system (RDBMS) such as Microsoft SQL Server, a flat file, a spreadsheet, or any other data store which the business tier needs access to.

These tiers do not necessarily correspond to physical locations on the network. For example, all three tiers can exist on a single computer or just two computers. With just two computers, one computer might be a Windows 95–based computer running Internet Explorer 4.0 as its browser. The second computer might be a Windows NT–based server computer running both Internet Information Server and Microsoft SQL Server. Of course, this is just one example. Instead of IIS as your middle tier, you might use MTS and straight DCOM.

The more traditional way to implement a three-tier application is to spread the load over several machines. This is a main advantage of three-tier application development. By using it, you can minimize the footprint of your application on the client systems. For example, one server can run SQL Server and another server can run MTS and IIS. If the communication from the presentation tier (provided through IIS) involves RDS and the marshaling of ADO recordsets, you only need to install the RDS client components. The rest of the MDAC stack is installed (redistributed) on the server that runs MTS and IIS. Of course, you do not have to use RDS to marshal an ADO recordset from the business tier to the presentation tier. You can use straight DCOM to marshal the ADO recordset from the business tier to the presentation tier. By using DCOM, you can replace the ADO recordset with an array or a simple string, which is parsed by the presentation tier for presentation to the user.

Note   ADO was first deployed with Internet Information Server 3.0, in support of three-tier Web-based applications. This means that ADO is typically used on the server and not on the client. The Remote Data Service client (which installs with Internet Explorer 4.0) enables you to provide a thin client, with minimal installation or overhead, to manage any kind of data—for example, an ADO recordset, a SafeArray, or a comma-delimited string. Because of this, you do not have to install the complete MDAC stack on your clients.

Another advantage of the three-tier model is object reusability. By developing function-specific objects for each of the tiers, you create a very flexible model that can be adapted for many different applications. For example, if you have a business tier object that implements the business rule that every employee must have a first and last name, you can use this object in any application that deals with employees.

Redistribution with ActiveX controls or active documents has been another challenging area for developers. For Microsoft Visual Basic developers, the .inf file generated by the Visual Basic Setup Wizard, in particular, needs changes to correctly install the MDAC stack. For more information, see Knowledge Base article Q184630 HOWTO: Use RDS Within a VB ActiveX Document.

Pros and Cons of Using the Redistribution Provided by Microsoft

Should a developer use the redistribution provided by Microsoft? Usually, this question arises because the developer wants only a particular component, or because Setup requires a silent, nonrebooting installation. It is possible to craft your own redistribution. To do this with MDAC 1.5, see the Knowledge Base article Q178842 (FILE: Mdacred.exe Required Files to Redistribute MDAC 1.5). An MDAC 2.0 version of this article has not been written at this time; however, you can find the essential information in this article's MDAC 2.0 components file list.

It is not a trivial task to create a robust, comprehensive MDAC redistribution mechanism. It is not enough to simply dump the files into a directory and register them. Here are some of the issues to watch for:

• Is the file currently loaded in memory? If so, you must use the Windows API to install and register the file on reboot. The Setup API functionality, included with the Platform SDK, supports this; but this implies your redistribution mechanism will be written in C++ or invoke a C++–based DLL.
  
  
• In most case, to register ODBC drivers you must actually install ODBC. The Microsoft Technical Support ODBC 3.0 installation assumes you have a complete distribution of the new version of ODBC in a directory, and explicitly uses LoadLibrary on the new ODBC version to register the ODBC drivers. However the official redistribution uses a utility, Odbcconf, to explicitly register ODBC drivers after reboot. The advantage of the former approach is that there is one less piece of redistribution to test (or to break!), and that reboot is needed only to register any MDAC file that is currently needed in memory. Odbcconf implies a reboot to complete installation.
  
  
• OLE DB, ADO, and RDS components must be installed into the correct location and registered from there. That is, you must change the current directory to the location of the DLL (especially for OLE DB DLLs) before registering them. Otherwise, registration will fail, particularly for the OLE DB Provider for ODBC Drivers (although the problem is not limited to this provider).
  
  
• Testing a redistribution mechanism can be tedious. You must test with a variety of clean operating systems, as well as with key products or technologies installed. This is to ensure, for example, that your redistribution mechanism properly handles file versioning. Systems should include Windows 95, Windows 95 OSR2, Windows NT 4.0 Server (and Windows NT 4.0 Workstation, although in the author's experience this is less of a necessity), Windows 98, and soon, Windows 2000. Now add service packs, Web browsers, and significant products such as database servers and office application software, and the permutations for testing become increasingly complex.

  Professional disk imaging software can make this testing process quicker, reducing the time to restore an operating system configuration from hours to minutes. In addition, the author recommends a large hard disk (minimum 4 GB) on your redistribution testing machine, with at least half of the space devoted solely to storing images for various operating systems. A suite of tests that can quickly test OLE DB, ADO, and RDS (as well as drivers or providers you need) is essential. The QueryDemo samples for both ODBC and OLE DB are an easy way to verify them. For ADO, use code that exercises each of the ADO objects by instantiating each of the objects and executing the more significant methods (BeginTrans, Open, Execute, AddNew, and so forth). During testing for the MDAC 1.5 redistribution, the author found one scenario where creating Parameter objects did not work if a single OLE DB DLL was not registered.

• The MDAC stand-alone Setup, MDAC redistribution, and Data Access SDK are built to detect the dependencies that MDAC components have with each other. The most common omission by users who build their own redistribution is the dependency between ODBC 3.5 and the OLE DB Provider for ODBC Drivers. If your Setup does not take this into account, you will break other applications on your customer's machines. It might not happen with every customer you distribute too, but it will happen.

Size of the redistribution is a valid justification for creating your own redistribution solution. However, if you do this the author strongly recommends using professional redistribution software. These products can get around many of the issues mentioned in the preceding list—such as gracefully handling updating files currently loaded in memory. The Setup API, included with the Platform SDK, is an excellent resource for creating a Setup in C/C++. It is also the basis for much of Microsoft Technical Support's efforts to help Microsoft customers handle redistribution issues.

Beware of getting caught in the trap of "I just want this one component." Often the component has dependencies. If you fail to consider them, installing your application could have unintended consequences for your customers and for other software they have already installed.

Conclusion

Numerous Knowledge Base articles exist to help customers with MDAC redistribution, but each deals with a single piece of the puzzle only. This article explains how the pieces fit together to provide a comprehensive vision of MDAC redistribution.

In 1997, Microsoft Technical Support and the product group worked to provide a robust, complete MDAC redistribution solution for customers using these technologies. MDAC 2.0 represents, by far, the most comprehensive and complete solution for developers. The product group and support will continue to improve the MDAC redistribution process.

Bibliography

The following Knowledge Base articles can be found at the Microsoft Technical Support Web site by searching "Support Online" at http://support.microsoft.com/support/.

Q164529  FILE: Updated Automation System Files

Q165487  Incorrect or Garbled Text on Tab Labels in Properties

Q168122  HOWTO: Redistributing ADO 1.0 or ADO/R 1.0 with OLE/DB 1.1

Q172394  FILE: Adoreg.exe License Key Registration DLL and ADO Use Tips

Q172406  FILE: ADOREGEX.EXE: Components to Redistribute ADO 1.0/1.1

Q173487  INFO: ADO 1.1 QFE Download Now Available (Updates ADO 1.0)

Q173611  FIX: ADO GetChunk Method Breaks Blob Data for DBCS

Q174191  SAMPLE: ODBC 3.0 Installation

Q176562  FILE: Clsidvw.exe OLE/Createable Objects Registry Diagnostic

Q176874  HOWTO: Distributing RDS Client with Visual Basic Setup Wizard

Q177913  HOWTO: Use the MDAC Stand-alone Setup EXE in Unattended Mode

Q178842  FILE: Mdacred.exe Required Files to Redistribute MDAC 1.5

Q178843  FILE: Required Files to Redistribute ODBC Version 3.5

Q178852  INFO: OLE DB Provider for ODBC Now an ODBC 3.5 Core Component

Q181126  INFO: Redistribution for MDAC 1.5 Components Available

Q183092  PRB: MDAC Stand-alone Setup Dialog Overly Large on Windows 95

Q184265  HOWTO: Redistribute MDAC 1.5 Components with Visual Basic 5 Apps

Q185622  HOWTO: Adding the MDAC Redistribution Setup to CAB Files

Q185963  FIX: Updated RDS Msadc11.cab for Internet Explorer Download

Q184630  HOWTO: Use RDS Within a VB ActiveX Document