1. Microsoft Data Access Components
Introduction
Microsoft Data Access Components, commonly abbreviated MDAC is a group of
Microsoft technologies that interact together as a framework that allows programmers a
uniform and comprehensive way of developing applications for accessing almost any
data store. It is made up of various components: ActiveX Data Objects (ADO), OLE DB,
and Open Database Connectivity (ODBC). There have been several deprecated
components as well, such as the Microsoft Jet Database Engine, MSDASQL, and Remote
Data Services (RDS). Some components have also become obsolete, such as the former
Data Access Objects API and Remote Data Objects.
The first version of MDAC was released in August 1996, and according to statements
from Microsoft was more of a concept than a stand-alone program and had no widespread
distribution method, though later Microsoft released upgrades to MDAC as web-based
redistributable packages. Eventually, later versions were integrated with Microsoft
Windows and in MDAC 2.8 SP1 they ceased offering MDAC as a redistributable
package. Throughout its history MDAC has been the subject of several security flaws,
which lead to attacks such as an escalated privileges attack, although the vulnerabilities
were generally fixed in later versions and fairly promptly. The current version is 2.8
service pack 1, but the product has had many different versions and many of its
components have been deprecated and replaced by newer Microsoft technologies.
Architecture
The latest version of MDAC (2.8) consists of several interacting components, all of
which are Windows specific except for ODBC (which is available on several platforms).
MDAC architecture may be viewed as three layers: a programming interface layer,
consisting of ADO and ADO.NET, a database access layer developed by database
vendors such as Oracle and Microsoft (OLE DB, .NET managed providers and ODBC
drivers), and the database itself. These component layers are all made available to
1

2. applications through the MDAC API. The Microsoft SQL Server Network Library, a
proprietary access method specific to Microsoft SQL Server, is also included in the
MDAC. Developers of Windows applications are encouraged to use ADO or ADO.NET
for data access, the benefit being that users of the application program are not constrained
in their choice of database architecture except that it should be supported by MDAC.
Naturally, developers still have the choice of writing applications which directly access
OLE DB and ODBC.
Microsoft SQL Server Network Library
The Microsoft SQL Server Network Library (also known as Net-Lib) is used by the
Microsoft SQL Server to read and write data using many different network protocols.
Though Net-Lib is specific to the SQL Server, Microsoft includes it with MDAC. The
SQL Server uses the Open Data Services (ODS) library to communicate with Net-Lib,
which interfaces directly with the Windows NT operating system line's Win32
subsystem. The SQL Server Network Library is controlled through the use of a Client
Network Utility, which is bundled with the SQL Server.
2

3. Each Net-Lib supported network protocol has a separate driver (not to be confused with a
device driver), and has support for a session layer in its protocol stack. There are two
general types of Net-Lib: the primary and the secondary. The primary Net-Lib consists of
a Super Socket Net-Lib and the Shared Memory Net-Lib, while there are numerous
secondary Net-Libs, including TCP/IP and named pipes network libraries (named pipes
are a method of communicating with other processes via a system-persistent pipeline that
is given an identity). The Microsoft OLE DB Provider for SQL Server (SQLOLEDB)
communicates via primary Net-Libs.
The Super Socket Net-Lib deals with inter-computer communications and coordinates the
secondary Net-Libs — though the TCP/IP secondary Net-Lib is an exception in that it
calls on the Windows Socket 2 API directly. The Banyan VINES, AppleTalk, Servernet,
IPX/SPX, Giganet, and RPC Net-Libs were dropped from MDAC 2.5 onwards. The
Network Library router had the job of managing all these protocols, however now only
the named pipes secondary Net-Lib is managed by the router. The Super Socket Net-Lib
also handles data encryption via the use of the Windows SSL API.
The Shared Memory Net-Lib, on the other hand, manages connections between multiple
instances of SQL Server that exist on one computer. It uses a shared memory area to
communicate between the processes. This is inherently secure; there is no need for data
encyption between instances of SQL Server that exist on one computer as the operating
system does not allow any other process access to the instances' area of shared memory.
Net-Lib is also able to support the impersonation of a logged in user's security context for
protocols that support authenticated connections (called trusted connections). This allows
Net-Lib to provide an integrated logon authentication mechanism via the use of Windows
Authentication. Windows Authentication is not supported on Windows 98 or Windows
Me.
OLE DB
OLE DB (also called OLEDB or OLE-DB) allows MDAC applications access to
different types of data stores in a uniform manner. Microsoft has used this technology to
3

4. separate the application from the data store that it needs to access. This was done because
different applications need access to different types and sources of data, and do not
necessarily need to know how to access technology-specific functionality. The
technology is conceptually divided into consumers and providers. The consumers are the
applications that need access to the data, and the provider is the software component that
exposes an OLE DB interface through the use of the Component Object Model (or
COM).
OLE DB is the database access interface technology used by MDAC. OLE DB providers
can be created to access such simple data stores as a text file or spreadsheet, through to
such complex databases as Oracle and SQL Server. However, because different data store
technology can have different capabilities, OLE DB providers may not implement every
possible interface available. The capabilities that are available are implemented through
the use of COM objects - an OLE DB provider will map the data store technology's
functionality to a particular COM interface. Microsoft calls the availability of an interface
to be "provider-specific" as it may not be applicable depending on the database
technology involved. Additionally, however, providers may also augment the capabilities
of a data store - these capabilities are known as services in Microsoft parlance.
The Microsoft OLE DB Provider for SQL Server (SQLOLEDB) is the OLE DB provider
that Microsoft provides for the Microsoft SQL Server from version 6.5 upwards.
According to Microsoft, SQLOLEDB will be "the primary focus of future MDAC feature
enhancements [and] will be available on the 64-bit Windows operating system."
ODBC
Open Database Connectivity (ODBC) is a native interface that is accessed through a
programming language (usually C) that can make calls into a native library. In MDAC
this interface is defined as a DLL. A separate module or driver is needed for each
database that must be accessed. The functions in the ODBC API are implemented by
these DBMS-specific drivers. The driver that Microsoft provides in MDAC is called the
SQL Server ODBC Driver (SQLODBC), and (as the name implies) is designed for
Microsoft's SQL Server. It supports SQL Server v6.5 and upwards. [3]
ODBC allows
4

5. programs to use SQL requests that will access databases without having to know the
proprietary interfaces to the databases. It handles the SQL request and converts it into a
request that the individual database system understands.
ADO
ActiveX Data Objects (ADO) is a high level programming interface to OLE DB. It uses a
hierarchical object model to allow applications to programmatically create, retrieve,
update and delete data from sources supported by OLE DB. ADO consists of a series of
hierarchical COM-based objects and collections, an object that acts as a container of
many other objects. A programmer can directly access ADO objects to manipulate data,
or can send an SQL query to the database via several ADO mechanisms. ADO is made
up of nine objects and four collections.
The collections are:
1. Fields: This collection contains a set of Field objects. The Collection can be used
in either a Recordset object or in a Record object. In a Recordset object, each of
the Field objects that make up the Fields collection corresponds to a column in
that Recordset object. In a Record object, a Field can be an absolute or relative
URL that points into a tree-structured namespace (used for semi-structured data
providers like the Microsoft OLE DB Provider for Internet Publishing) or as a
reference to the default Stream object associated with that Record object.
2. Properties: An object can have more than one Property object, which are
contained in the object's Properties collection.
3. Parameters: A Command object can have several Parameter commands to
change its predefined behaviour, and each of the Parameter objects are contained
in the Command object's Parameters collection
4. Errors: All provider created errors are passed to a collection of Error objects,
while the Errors collection itself is contained in a Connection object. When an
ADO operation creates an error, the collection is cleared and a new group of Error
objects are created in the collection.
5

6. The objects are:
1. Connection: The connection object is ADO's connection to a data store via OLE
DB. The connection object stores information about the session and provides
methods of connecting to the data store. As some data stores have different
methods of establishing a connection, some methods may not be supported in the
connection object for particular OLE DB providers. A connection object connects
to the data store using its 'Open' method with a connection string which specifies
the connection as a list of key value pairs (for example:
"Provider='SQLOLEDB';Data Source='TheSqlServer'; Initial
Catalog='Northwind';Integrated Security='SSPI';") The start of which
must identify the type of data store connection that the connection object requires.
This must be either:
a. an OLE DB provider (for example SQLOLEDB), using the syntax
"provider="
b. a file name, using the syntax "file name="
c. a remote provider and server, using the syntax "Remote provider="
and "Remote server="
d. an absolute URL, using the syntax "URL="
2. Command: After the connection object establishes a session to the data source,
instructions are sent to the data provider via the command object. The command
object can send SQL queries directly to the provider through the use of the
CommandText property, send a parameterised query or stored procedure through
the use of a Parameter object or Parameters collection or run a query and return
the results to a dataset object via the Execute method. There are several other
methods that can be used in the Command object relating to other objects, such as
the Stream, RecordSet or Connection objects.
6

7. 3. Recordset: A recordset is a group of records, and can either come from a base table
or as the result of a query to the table. The RecordSet object contains a Fields collection
and a Properties collection. The Fields collection is a set of Field objects, which are the
corresponding columns in the table. The Properties collection is a set of Property objects,
which defines a particular functionality of an OLE DB provider. The RecordSet has
numerous methods and properties for examining the data that exists within it. Records
can be updated in the recordset by changing the values in the record and then calling on
the Update or UpdateBatch method. Adding new records is performed through the
AddNew function and then by calling on the Update or UpdateBatch method. Records are
also deleted in the recordset with the Delete method and then by calling on the Update
method. However, if for some reason the deletion cannot occur, such as because of
violations in referential integrity, then the recordset will remain in edit mode after the call
to the Update method. The programmer must explicitly call on the CancelUpdate
function to cancel the update. Additionally, ADO can rollback transactions (if this is
supported) and cancel batch updates. Recordsets can also be updated in one of three
ways: via an immediate update, via a batch update , or through the use of transactions:
a. Immediate: The recordset is locked using the adLockOptimistic or
adLockPessimistic lock. The data is updated at the data source after the record is
changed and the Update method is called.
b. Batch: The recordset is locked using adLockBatchOptimistic and each time
Update is called the data is updated in a temporary buffer. Finally, when
UpdateBatch is called the data is completely updated back at the data source. This
has the advantage of it all being done in memory, and if a problem occurs then
UpdateCancel is called and the updates are not sent to the data source
c. Transaction: If the OLE DB provider allows it, transactions can be used. To start
the transaction, the programmer invokes the BeginTrans method and does the
required updates. When they are all done, the programmer invokes the CommitTrans
7

8. method. RollbackTrans can be invoked to cancel any changes made inside the
transaction and rollback the database to the state before the transaction began
4. Record: This object represents one record in the database, and contains a fields
collection. A RecordSet consists of a collection of Record objects.
5. Stream: A stream, mainly used in a RecordSet object, is a means of reading and
writing a stream of bytes. It is mostly used to save a recordset in an XML format ,
to send
commands to an OLE DB provider as an alternative to the CommandText object and to
contain the contents of a binary or text file.
6. Parameter: A parameter is a means of altering the behaviour of a common piece of
functionality, for instance a stored procedure might have different parameters passed to it
depending on what needs to be done - these are called parameterised commands.
7. Field: Each Record object contains many fields, and a RecordSet object has a
corresponding Field object also. The RecordSet object's Field object corresponds to a
column in the database table that it references.
8. Property: This object is specific to the OLE DB provider and defines an ability that
the provider has implemented. A property object can be either a built-in property — it is
a well defined property implemented by ADO already and thus cannot be altered — or
can be a dynamic property — defined by the underlying data provider and can be
changed
9. Error: When a OLE DB provider error occurs during the use of ADO, an Error object
will be created in the Errors collection. Other errors do not go into an Error object,
however. For instance, any errors that occur when manipulating data in a RecordSet or
Field object are stored in a Status property.
ADO.NET
ADO.NET is the latest version of ADO (after ADO 2.8, now often referred to as ADO
Classic) and is part of the MDAC 2.8 stack alongside classic ADO. It is built around
Microsoft .NET. Though sometimes seen as an evolutionary step up from ADO, some
fundamental structural changes were made by Microsoft. ADO.NET runs through a .NET
8

9. Managed Provider, a modified version of an OLE DB provider specifically designed
for .NET. The object structure is no longer built around a Recordset object. Instead a
Dataset object is used to contain data gathered from multiple sources. This is transparent
to the programmer. Unlike the old ADO Recordset, the Dataset's design allows for
disconnected data. Conceptually, a Dataset object can be seen as a small in-memory
relational database in its own right that allows for manipulation of data in any direction (a
Recordset was a forward-only reader). In order to propagate changes back into the
database, a Dataadapter object is used that transfers data from between the data source
and the DataSet object. Cursors were also deprecated in ADO.NET, being replaced with a
Datareader object, which is used to efficiently process a large list of results one record at
a time without storing them.
Deprecated & obsolete components
MDAC is a continually evolving component framework. As such, there have been several
components that were previously part of it but have since been deprecated or removed
entirely from the framework.
Microsoft Jet Database Engine and JRO
Jet stands for Joint Engine Technology and was a database engine used for Microsoft
Access, Microsoft Exchange Server and Visual Basic. Jet was part of a Relational
Database Management System (RDBMS) and offered a single interface that other
software could use to access Microsoft databases. Jet also provided support for security,
referential integrity, transaction processing, indexing, record, page locking and data
replication. In later versions of Jet, the engine was extended to run SQL queries, store
character data in Unicode format, create views, and allowed bi-directional replication
with the Microsoft SQL Server. It has since been superseded by MSDE.
There were three modules to Jet. One was the Native Jet ISAM Driver, a Jet dynamic
link library (DLL) that could directly manipulate Microsoft Access database files (MDB),
which was a modified form of an Indexed Sequential Access Method (ISAM) database.
9

10. Another one of the modules were the ISAM Drivers, DLLs that allowed access to ISAM
databases, among them being Xbase, Paradox, Btrieve and FoxPro files. The final module
was the Data Access Objects (DAO) DLL, DAO allowed programmers access to the Jet
engine. It was basically an object-oriented data language used by Access Basic and
Visual Basic application developers to access Jet.
Similarly, the Microsoft Jet OLE DB Provider and Replication Objects (JRO) which
allowed replication between Jet data sources was removed from MDAC 2.6
MSDASQL and Oracle ODBC
The Microsoft OLE DB Provider for ODBC, or MSDASQL, was an OLE DB provider for
allowing ActiveX Data Objects access to databases via any ODBC driver. There were
several OLE-DB providers supplied by Microsoft (providers available were for the
Indexing Service, Active Directory, Jet, SQL Server, Oracle and Internet Publishing),
however unless specified, MSDASQL was the default provider used by ADO. After
MDAC 2.5 both the Oracle ODBC driver and MSDASQL supported Oracle 7 and
partially supported Oracle 8i. Features that were not supported were:
1. CLOB, BLOB, BFILE, NCHAR, NCLOB, and NVARCHAR2 Oracle datatypes
2. Unicode support for Oracle 7.x and 8i
3. multiple client instances of Oracle
4. nested outer joins
Microsoft deprecated the MSDASQL component for their 64-bit operating systems and
the Microsoft Oracle ODBC driver was later superseded by a .NET Managed Oracle
Provider, which supported Oracle 9i.
Remote Data Services (RDS)
Remote Data Services (RDS) allowed the retrieval of a set of data from the server, which
the client then altered in some way and then sent back to the server for further processing
With the popular adoption of Transact-SQL, which extends SQL with such programming
10

11. constructs as loops and conditional statements, this became less necessary and it was
eventually deprecated in MDAC 2.7. Microsoft produced SOAP Toolkit 2.0, which
allows clients to do this via an open XML-based standard.
SQLXML
SQLXML was designed for SQL Server 2000, but was deprecated with MDAC 2.6. It
allowed Microsoft's relational database to be viewed by XPath and allowed data to
viewable as an XML file. It has not actually been deprecated but has been removed from
later versions of MDAC, though Microsoft does provide it as a downloadable component
and will support it on their 64-bit operating systems.
Obsolete components
Several components have been completely removed from MDAC by Microsoft and are
no longer supported. They are:
1. ESQL/C: Embedded SQL (also known as E-SQL or ESQL/C) is a way of using
SQL when programming in Visual C. Microsoft dropped support for this after
SQL Server 6.5 was released, though they did license some of the ESQL/C run-
time environment to a company called Micro Focus, who develops COBOL
compilers and tools.
2. DAO: DAO, or Data Access Objects were an object oriented interface created by
Microsoft which allowed early versions of Microsoft Access and Visual Basic the
Jet database engine. Later (in version 3.5) it was able to bypass the Jet engine
altogether and directly access ODBC data sources.
3. RDO: Remote Data Objects, or RDO, was a Microsoft technology that allowed
for the creation of interfaces that directly called on ODBC. RDO version 2.0 was
the final version developed by Microsoft.
4. DB-Library: a C-based API that allowed an application to interact with SQL
Server. It will not be supported on any product after SQL Server 2000, and no
added features were added after SQL Server 6.5.
11

12. Several Versions of MDAC
Microsoft has released several versions of MDAC throughout its lifetime. The
distribution method has been varied and the feature set is different for each version.
MDAC 1.0: MDAC 1.0 was first released in August 1996.According to Microsoft,
"MDAC 1.0 existed more as concept than a coordinated, stand-alone setup program." The
MDAC 1.0 stack consisted of ODBC 3.0, OLE DB 1.1, ADO 1.0, and the Advanced Data
Connector (ADC) 1.0 — which according to Microsoft was the precursor to the Remote
Data Service of MDAC 1.5. It also included ODBC drivers for Access/Jet, SQL Server
and Oracle databases. MDAC 1.0 was released via several mechanisms: the Advanced
Data Connector shipped with Internet Information Server (IIS) 3.0 and as a downloadable
cab file; OLE DB 1.1 and ADO 1.0 shipped with the OLE DB 1.1 SDK, which came with
Visual Studio 97 and was also downloadable. MDAC 1.0 came with Active Server Pages,
that itself came in IIS 3.0, and also came with Visual InterDev 1.0.
MDAC 1.5: MDAC 1.5 was released between September 1997 and March 1998, and
involved a more centralised distribution mechanism than MDAC 1.0. It was released with
Microsoft Internet Explorer 4.0, the Internet Client SDK 4.0 and through a CD-ROM
given out at the 1997 Professional Developers Conference (PDC). There were four
versions of MDAC 1.5:
a. MDAC 1.5a: downloadable from Microsoft's website
b. MDAC 1.5b: came with Windows NT 4.0 Option Pack & Office 97
c. MDAC 1.5c: fixed issues with ADO threading and ODBC Connection Pooling and
was distributed via the Microsoft website. It only came with the ADO/MDAC
runtime components.
12

13. d. MDAC 1.5d: came included with Windows 98 and Internet Explorer 4.01 service
pack 1
MDAC 1.5 consisted of:
a. ODBC 3.5
b. OLE DB 1.
c. ADO 1.5
d. Remote Data Service 1.5, which superseded the Advanced Data Connector.
This version of MDAC had a security flaw that made it vulnerable to a escalated
privileges attack. The vulnerability caused systems that had both IIS and MDAC installed
to give an unauthorized web user the ability to execute shell commands on the IIS system
as a privileged user and use MDAC to tunnel SQL and other ODBC data requests
through the public connection to a private back-end network when on a multi-homed
Internet-connected IIS system. It also allowed the user to gain unauthorized access to
secured, non-published files on the IIS system .MDAC 1.5 was the last data access
component release supported under Windows NT 3.51 SP5.
MDAC 2.0: MDAC 2.0 was distributed with the Data Access 2.0 SDK and included the
contents of MDAC 1.5, the ODBC 3.5 SDK and the OLE DB 1.5 SDK, and the OLE DB
for OLAP Specification; it also had included many updates to the core product, including
a security feature added to the RDS which prevented it from being used maliciously an
IIS server This version came included in Windows NT 4.0 SP4, and also with Visual
Studio 6.0, which came with the full Data Access SDK.
MDAC 2.1: MDAC 2.1 was distributed with SQL Server 7.0 and SQL Server 6.5 SP5;
MDAC 2.1 SP1 was distributed with Internet Explorer 5; MDAC 2.1 SP1a (GA) was
distributed with Microsoft Office 2000, BackOffice 4.5 and Visual Studio 98 SP3;
however, none of these versions of MDAC were released to the general public via the
world wide web. MDAC 2.1 SP2 was distributed from Microsoft's website. The
components that were included with 2.1 were:
13

14. a. ADO 2.1
b. RDS 2.1
c. OLE DB 2.1
d. the OLE DB Provider for ODBC, SQL Server and Oracle
e. JRO 2.1
f. a Jet driver
g. RDO
This version had security vulnerabilities whereby an unchecked buffer could allow an
elevated privileges attack. This was found some time later and it affected MDAC 2.1, 2.5
and 2.6 and was addressed in a later patch.
MDAC 2.5: MDAC 2.5 was released on February 17, 2000 and distributed with
Windows 2000, and the MDAC service packs were released in parallel with the Windows
2000 service packs. They were also distributed through Microsoft's website. Three
service packs were released. The components included with 2.5 were:
a. ADO 2.5
b. ADO MD 2.5
c. ADOX 2.5
d. RDS 2.5
e. OLE DB 2.5
f. many OLE DB Providers
g. JRO 2.5
h. ODBC 3.51
i. many ODBC
j. drivers
k. many Jet drivers
Several issues were found in this version of MDAC. When using OLE DB Session
Pooling, Microsoft COM+ would try to continuously load and unload OLE DB, and a
conflict could arise that caused the OLE DB Session Pooling to run at 100% CPU usage.
This was later fixed. Microsoft published a full list of bugs fixed in MDAC 2.5 Service
14

15. Pack 2 and MDAC 2.5 Service Pack 3. A security vulnerability also existed (later fixed)
whereby an unchecked buffer in was found in the SQL Server Driver. This flaw was
introduced in MDAC 2.5 SP2.
MDAC 2.6: MDAC 2.6 was released in September 2000 and was distributed through the
web and with Microsoft SQL Server 2000 MDAC 2.6 RTM, SP1 (released June 20,
2001), and SP2 (released June 11, 2002) were distributed in parallel with the Microsoft
SQL Server 2000 service packs, and could also be downloaded from the Microsoft
website.
Beginning with this version of MDAC, Microsoft Jet, Microsoft Jet OLE DB Provider,
and the ODBC Desktop Database Drivers were not included. Instead, these could be
installed manually. Microsoft also released an alert warning that MDAC 2.6 should not
be installed on an SQL Server 7.0 Cluster, because "if you install MDAC 2.6 or later on
any node in the cluster, directly or through the installation of another program, it may
cause a catastrophic failure of the SQL Server Agent or other SQL Server services." This
issue affected Veritas Software's Backup Exec 9.0 for Windows Servers, because it
installs Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) as its database.
Revision 4367 installed MDAC version 2.6 SP2 while revision 4454 installed MDAC
version 2.7 SP1, which did not have the problem.
MDAC 2.7: MDAC 2.7 was released in October 2001 through Microsoft's website. A
refresh release was issued in April 2002 through the release of Windows XP and through
Microsoft's website. Version 2.7 was available in U.S. English, Chinese (Traditional and
Simplified), German, Japanese, Korean, Brazilian Portuguese, Czech, Danish, Greek,
Slovak, Slovenian, Spanish, Finnish, French, Hungarian, Italian, Dutch, Norwegian,
Polish, Portuguese, Russian, Swedish, and Turkish. Hebrew and Arabic were only
available through Windows XP.
The main feature change was support for Microsoft's 64-bit operating system, however
support for Banyan VINES was also dropped from this version of MDAC. There were
several known issues.MDAC 2.7 continued causing connectivity problems on clustered
15

16. servers running Microsoft SQL Server 6.5 or SQL Server 7.0, with no workaround
provided by Microsoft. When creating or configuring ODBC data source names (DSNs)
using the Microsoft SQL Server ODBC driver the network library protocol might
unexpectedly switch to TCP/IP, even if the DSN was configured to use named pipes. [48]
This issue was found by InfoWorld reporter Randall C. Kennedy, who identified that the
change was actually made in MDAC 2.6 but was never documented. It was discovered
when testing client/server database workloads on a Windows XP computer - InfoWorld
claims that although overall server CPU utilization rose by only 8 percent using TCP/IP,
context switches per second dropped by more than 150 percent for a 10-user workload.
They were unimpressed that a fundamental functional change to the default behaviour of
Net-Lib occurred without more than a passing mention in an unrelated document.
Windows XP users also sometimes experienced problems connecting to SQL Server
because SQL Server attempts to use certificates it finds on the local computer, however if
there is more than one certificate available it did not know which one to use. When
attempting to use Microsoft Analysis Services 2000 RTM, an error would sometimes
appear when trying to browse cubes. Microsoft also discovered a problem in Windows
95, Windows 98, and Windows Me's setup program which prevented the MDAC
installation program from rolling back when it encountered an installation error.
Several security issues were resolved by Microsoft for MDAC 2.7. David Litchfield of
Next Generation Security Software Ltd reported a security vulnerability that results
because one of the ODBC functions in MDAC that is used to connect to data sources
contained an unchecked buffer. Another vulnerability that was fixed was one whereby an
attacker could respond to an SQL Server discovery message broadcast by clients with a
specially crafted packet that could cause a buffer overflow. Another flaw was found
whereby code could be executed remotely when the attacker responded to the broadcast
with another specially crafted packet .
16

17. MDAC 2.8: MDAC 2.8 was released in August 2003 and distributed with Microsoft
Windows Server 2003, as well as on Microsoft's Data Access Technologies
website. It did not introduce any new features to the product but fixed a number
of bugs and security issues — a reg file (automates changes to the registry) was
removed that made the server run in an "unsafe" mode whereby the RDS could
be exploited to gain unauthorised access to the system and a new restriction was
imposed on the length of the Shape query string .There were also several ODBC
Administrator changes.
On May 23, 2005 Brad Rhodes (Lead Program Manager of Microsoft Data Access
Technologies) announced that MDAC 2.8 SP1 was the last stand-alone redistributable of
MDAC that Microsoft will ship. MDAC is now an official component of the Microsoft's
operating system, though they will be providing ongoing bug and security fixes to
previously released versions of the web-distributable version. However, Microsoft have
created a new component called the SQL Native Client (SQLNCLI), which is a stand
alone data access API that has combined the OLE DB and ODBC libraries into one DLL.
Checking for MDAC version
There are two ways of checking the version of MDAC that is installed on a computer.
1. Use the Component Checker tool.
2. Check the version information that is stored in the registry.
Install and Use the Component Checker Tool
The most reliable way to determine which version of MDAC is installed is to compare
the version number of each MDAC DLL file to a list of the DLL files that are shipped
with each MDAC version. The Component Checker can help you to do this. It checks the
files on the computer, compares them to a list from each version of MDAC, and reports
the closest match.
To use Component Checker to check the MDAC version, follow these steps:
1. From the Start menu, click Run.
2. In the Open text box, type c:comcheckcomcheck.exe and then click OK.
17

18. 3. In the Component Checker - Choose Analysis Type dialog box, select Perform
Analysis of your machine and automatically determine the release version,
and then click OK.
4. The program attempts to identify the MDAC version on your computer by
scanning all of the core MDAC files and registry settings. This process normally
takes several minutes. When finished, you should receive the following
message:The MDAC version that is closest to the version on your computer is
'XXXX'.
5. Click OK.
•
A summary of the Component Checker scan appears. Note that the Dir
FileDescription and FileSize errors can be safely ignored.
••
Check the Version Information Stored in the Registry
Although not the most reliable way to check the MDAC version, checking the registry for
the version information is an easy way to double-check this information (if you are not
Experiencing any MDAC-related issues).
The version information is found in the following key:
HKEY_LOCAL_MACHINESoftwareMicrosoftDataAccessFullInstallVer
To check the registry, follow these steps:
On the Start menu, click Run.
In the Open text box, type regedit and then click OK; this starts Registry Editor.
In the Navigation pane, drill-down to the following path:
HKEY_LOCAL_MACHINESoftwareMicrosoftDataAccess
In the Details pane, look in the Name column for FullInstallVer and Version. Each of
these keys will have corresponding version information in the Data column.
When finished, click Exit on the Registry menu to close Registry Editor.
Conclusion
18

19. Microsoft Data Access Components, commonly abbreviated MDAC, is a group of
Microsoft technologies that interact together as a framework that allows programmers a
uniform and comprehensive way of developing applications for accessing almost any
data store. It is made up of various components: ActiveX Data Objects (ADO), OLE DB,
and Open Database Connectivity (ODBC). There have been several deprecated
components as well, such as the Microsoft Jet Database Engine, MSDASQL, and Remote
Data Services (RDS). Some components have also become obsolete, such as the former
Data Access Objects API and Remote Data Objects. Supported Operating Systems are:
Windows 2000; Windows 98; Windows ME; Windows NT; Windows XP.
19