Re: Recommended data access model



This is from MDAC 2.8 SDK.

"The Role of ADO in MDAC
The Microsoft Data Access Components (MDAC) provide data access that is
independent of data stores, tools, and languages. It provides a
high-level, easy-to-use interface and a low-level, high-performance
interface to practically any data store available. You can use this
flexibility to integrate diverse data stores and use your choice of
tools, applications, and platform services to create the right
solutions for your needs. These technologies provide the basic
framework for general-purpose data access in Microsoft® Windows®
operating systems.

There are three primary technologies in MDAC. ActiveX® Data Objects
(ADO) is a high-level, easy-to-use interface to OLE DB. OLE DB is a
low-level, high-performance interface to a variety of data stores. Both
ADO and OLE DB can work with relational (tabular) and nonrelational
(hierarchical or stream) data. Finally, Open Database Connectivity
(ODBC) is another low-level, high-performance interface that is
designed specifically for relational data stores.

ADO provides a layer of abstraction between your client or middle-tier
application and the low-level OLE DB interfaces. ADO uses a small set
of Automation objects to provide a simple and efficient interface to
OLE DB. This interface makes ADO the perfect choice for developers in
higher level languages, such as Visual Basic and VBScript, who want to
access data without having to learn the intricacies of COM and OLE DB."

Do you see where ADO is "not recommended"? No? Read it again! Still
not? Guess you'll never get to be a knowledgeable MS insider then.

Still can't find it? Read on:

"Microsoft Data Access Components (MDAC)
The Microsoft® Data Access Components (MDAC) SDK documents the key
technologies that are part of Microsoft's strategy for providing access
to information across the enterprise.

Microsoft Data Access Components include ActiveX® Data Objects (ADO),
OLE DB, and Open Database Connectivity (ODBC). Data-driven
client/server applications deployed over the Web or a LAN can use these
components to easily integrate information from a variety of sources,
both relational (SQL) and non-relational.

If you have questions or need detailed information about properly
redistributing MDAC, see Redistributing MDAC for a description of the
distribution requirements for MDAC.

ActiveX Data Objects (ADO)
Microsoft ActiveX Data Objects (ADO) provides consistent,
high-performance access to data and supports a variety of development
needs, including the creation of front-end database clients and
middle-tier business objects that use applications, tools, languages,
or Internet browsers. The primary benefits of ADO are ease of use, high
speed, low memory overhead, and a small disk footprint.

ADO provides an easy-to-use interface to OLE DB, which provides the
underlying access to data. It uses a familiar metaphor - the COM
Automation interface - available from all leading Rapid Application
Development (RAD) tools, database tools, and languages.

OLE DB
Microsoft OLE DB is a set of interfaces that expose data from a variety
of relational and nonrelational sources by using the Component Object
Model (COM). OLE DB interfaces provide applications with uniform access
to data stored in diverse information sources. These interfaces support
the amount of DBMS functionality appropriate to the data store,
enabling the data store to share its data.

OLE DB comprises a programmatic model consisting of data providers,
which contain and expose data; data consumers, which use data; and
service components, which process and transport data (such as query
processors and cursor engines). In addition, OLE DB includes a bridge
to ODBC to enable continued support for the broad range of ODBC
relational database drivers."

Did you get it that time? NO? Geeesh. Well, see the part where it says,
". The primary benefits of ADO are ease of use, high speed, low
memory overhead, and a small disk footprint." Now tell me, who would
want THAT!


OK, maybe ADO is deprecated. Let's check that:

"Deprecated Components
Each of the following components is considered obsolete. While these
components are still supported in this release of the Microsoft® Data
Access Components (MDAC), they may be removed in the future. When
writing new applications, you should avoid using these deprecated
components. When modifying existing applications, you are strongly
encouraged to remove any dependency on these components.

ODBC Provider (MSDASQL)
You are strongly encouraged to use one of the native OLE DB Providers
instead of the Microsoft Open Database Connectivity (ODBC) Provider.
Native OLE DB Providers provide better application stability and
performance. Furthermore, native OLE DB Providers will be supported in
the future, whereas MSDASQL will not have any new features added to it,
will not be available on 64-bit, and will not be accessible from the
OLE DB NET Data Provider.

Remote Data Services (RDS)
Remote Data Services (RDS) is a proprietary Microsoft mechanism for
accessing remote data across the Internet or intranet. Microsoft is now
shipping the Microsoft Simple Object Access Protocol (SOAP) Toolkit 2.0
that enables you to access remote data using an open, XML-based
standard. Given the availability of the SOAP Toolkit 2.0, you should
migrate from RDS to SOAP. The SOAP 2.0 Toolkit 2.0 also includes sample
code for remotely accessing Microsoft ActiveX® Data Objects (ADO)
Recordsets.

Jet and Replication Objects (JRO)
The Microsoft Jet OLE DB Provider and other related components were
removed from MDAC 2.6. Microsoft has deprecated the Microsoft Jet
Engine, and plans no new releases or service packs for this component.
As a result, the Jet and Replication Objects (JRO) is being deprecated
in this release and will not be available in any future MDAC releases."

Did you see where ADO is deprecated? No? What can I say?

Doesn't this all explain about "knowledgeable MS insiders not
recommending DAO" ?

Still not convinced? I don't know what to say:
That ADO is crisp, clean and has a million (well maybe only a hundred
or so) capabilities that DAO never even thought of?
That Access and ADO work extremely well together?
That speed advantages of DAO over ADO are in nanoseconds?
That Lyle has written many successful applications (Access included)
over the last few years without any (except the behind the scenes
stuff) DAO at all.
That ADO, currently, is the only well known and popular technology one
can use in almost exactly the same way within VBA, VB, VBS, JavaScript
and ASP to interface with Databases?

.



Relevant Pages

  • Re: Table adapter ???
    ... ADO was a lightweight COM layer built on top of OLE DB. ... ADO and OLE DB updates came in downloads of the MDAC pack (Microsoft Data ... It also came with a OLE DB provider for ODBC which meant ...
    (microsoft.public.data.ado)
  • Re: Zugriff auf mySQL
    ... Weise des Zugriffs auf DBs unter ADO ist mehr oder weniger immer dieselbe. ... Damit Du ADO verwenden kannst, müssen die Microsoft ActiveX Data Objects (kurz MDAC, aktuelle Version 2.8) installiert sein (kostenlos bei Microsoft herunterzuladen oder auch ggf. ...
    (microsoft.public.de.vb.datenbank)
  • Re: Help with converting DAO to ADO
    ... Microsoft says: ... ADO: ActiveX Data Objects provides a high-level programming ... performant than coding to OLE DB or ODBC directly, ... and can be used from script languages ...
    (comp.databases.ms-access)
  • Re: ADO connection Open failure
    ... Jet database, the user must have read/write permission to the folder where ... the user has read/write permission to the shared drive. ... That is, either use ADO, or use DAO, not both. ... Microsoft Office 11.0 Object Library ...
    (microsoft.public.excel.programming)
  • Re: ADO error code 800a0c93
    ... Yes, it works now, without ADO Record Binding. ... Well the problem is in your RecordBinding code. ... It is this that Microsoft has never adequately documented. ... newsgroups with more experienced programmers and read their responses (in ...
    (microsoft.public.data.ado)