MORE INFORMATION
Q. What are the ActiveX Data Objects (ADO)?
A.
ActiveX Data Objects are a language-neutral object model that expose data
raised by an underlying OLE DB Provider. The most commonly used OLE DB Provider
is the OLE DB Provider for ODBC Drivers, which exposes ODBC Data sources to
ADO.
Q. Where can I get ActiveX Data Objects?
A. ADO is
part of the Microsoft Data Access Components (MDAC). ADO can be obtained from
the Free Downloads page on this Web site:
Q. Where is the documentation that comes with ADO?
A.
The documentation that comes with ADO is in html format and can be found by
downloading the MDAC Software Development Kit (SDK) from the preceding Web
site. Make sure to choose the Microsoft Data Access Components SDK Stand Alone
Setup option when downloading MDAC 2.0, or the Microsoft Data Access Components
SDK Update if downloading MDAC 2.1.
The documentation for the latest
version of ADO is also available online at:
The documentation for ADO is part of the Platform SDK
documentation that comes with the MSDN Library. In the MSDN Library, choose
Contents, then Platform SDK | Data Access Services | Microsoft Data Access
Components (MDAC) SDK | Microsoft ActiveX Data Objects (ADO).
Q. What
is Remote Data Service (RDS) for ActiveX Data Objects (ADO)?
A.
Remote Data Service (RDS) is used to transport Active Data Object Recordsets
from a server to a client computer. The resulting recordset is cached on the
client computer and disconnected from the server. RDS uses a subset of the ADO
Object model, the ADOR.Recordset, to provide a low-overhead, high-performance
way to marshal recordset data over a network or web.
Q. What is the
difference between the ADODB and ADOR objects?
A. The ADODB Library
contains additional server side objects (Connection, Command, Error,
Parameters, and so forth). These are best used within server side components to
communicate with the database.
The ADOR Library is a lighter weight
client that allows the manipulation of an existing recordset on the client. It
does not include the Connection, Command, Error, or Parameters commands. The
ADOR functionality is distributed with the ADO client components.
Q.
How do I get started using ADO with C++?
A. The best solution is to
use #import, which generates very thin classes around the ADO typelib and lets
you manipulate them in a syntax very close to the Visual Basic for Applications
(VBA) syntax. Most ADO samples are written using VBA, and #import lets you
translate with greater ease than, say, using Microsoft Foundation Class (MFC)
OLE's COleDispatchDriver or using COM programming directly. The list of
Microsoft Knowledge Base articles that follows will help you to use ADO with
#import:
220152 Sample: ADOVC1 Simple ADO/VC++ Application
173645 BUG: Access Violation in Msdaer.dll with _com_error Exceptions
173645 FILE: Adovcbtd.exe #import Using UpdateBatch and CancelBatch
184968 Adovcsp.exe Demonstrates Using Stored Procedures with ADO
182389 FILE: Adovcbm.exe ADO 1.5 with #import and Getrows/Bookmarks
166112 PRB: Conflict with EOF When Using #import with ADO
169496 INFO: Using ActiveX Data Objects (ADO) via #import in VC++
168354 INFO: Underlying OLE and OLEDB Provider Errors Are Exposed Through ADO
Additionally, the following articles can be found
when searching using Visual C++ as the product that will prove useful to ADO
developers:
167802 SAMPLE: EXCEPTEX Traps MFC and Win32 Exceptions
175784 INFO: Replacing #import's Exception Raising Mechanism
Q. How do I find Microsoft Knowledge Base (KB)
articles for ADO?
A. Connect to the Microsoft Knowledge Base on the
World Wide Web. To access the Microsoft Knowledge Base on the World Wide Web,
visit the following Microsoft Web site:
For additional information about how to use
the Microsoft Knowledge Base, click the article number below to view the
article in the Microsoft Knowledge Base:
129725 Obtaining Knowledge Base Articles on the World Wide Web
Q. How do I determine ADO's capabilities?
A. ADO is dependent upon the data provider it uses. The
easiest/quickest way is to check the Supports property to confirm that the
connection or recordset you opened supports the functionality you actually
need. You should also confirm that the CursorType, and LockType match what you
expected. If the underlying provider cannot support the cursor you requested,
ADO downgrades these properties to get the cursor that is closest to what you
requested.
A more in-depth approach involves analyzing the underlying
data provider you are using underneath ADO. The most common provider is the OLE
DB Provider for ODBC Drivers that exposes ODBC Data sources to ADO. You can use
the Properties collection(s) for the Connection, Command, Recordset, and Field
objects and compare the results displayed there to the OLE DB Specification and
the OLE DB Leveling Document, both included with the OLE DB SDK, available free
for download at this URL:
Note that ADO will not automatically define each value for each
property exposed in the collections. The property will only be set when the
operation you are performing with ADO actually needs to use that property
exposed by the underlying provider. This is for performance, and varies from
other object models such as DAO which initialize any and all properties whether
the operation you are performing utilizes them or not.
Using the
Recordset.Supports property is the easiest way to verify that what you expect
is actually what the provider exposed to you, given the specific type of
connection and recordset you have opened.