About CDO and ADO
[This is preliminary documentation and subject to change.]
CDO and ADO are designed to work in conjunction with one another. Applications use ADO to navigate, search and modify the properties of items in the Web Store, and use CDO to create and manage specific types of items, such as messages, contacts, appointments, messages containing meeting requests, and folders. Whereas ADO provides raw data access, CDO provides additional functionality that:
- Handles the creation and management of the various Internet standard stream formats for items such as messages, appointments, and contacts. These formats include the RFC 822 message format, the Multipurpose Internet Mail Extensions (MIME) format, the iCalendar format (for appointment exchange), and the vCard contact format. Unlike ADO objects, CDO objects automatically keep the item's stream in synchrony with the item's properties.
- Provides business logic used to simplify working with the raw data that comprises many objects in the Web Store and Active Directory. For example, the CDO Person object alleviates the need to remember all of the various attribute names used with User objects in Active Directory when performing the most routine tasks due to schema differences.
- Encoding and decoding of data into Internet standard transfer formats, such as the base64 and quoted-printable formats.
- Correlation of meeting request responses automatically into the master appointment object in a user's Calendar folder or a public folder.
Both CDO and ADO directly rely on the Exchange OLE DB Provider (ExOLEDB) to access data residing in Microsoft Exchange private and public information stores.
CDO objects can also be directly bound to ADO objects to increase performance by not requiring separate bindings to the item in a particular store. When bound, changes made with a CDO object can be saved back into the ADO object, and therefore only one session need be used when processing items using both CDO and ADO.