CDO and ADO
Topic Last Modified: 2007-11-09
Collaboration Data Objects (CDO) and Microsoft® ActiveX® Data Objects (ADO) are designed to work in conjunction with one another. Applications use ADO to navigate, search, and modify the properties of items in the Exchange store; they use CDO to create and manage specific types of items, such as messages, contacts, appointments, messages that contain meeting requests, and folders. Whereas ADO provides raw data access, CDO provides added functionality, which does the following:
- Handles the creation and management of 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 synch with the item's properties.
- Provides business logic that makes it easier to work with the raw data in many objects in the Exchange store and the Active Directory® directory service. For example, the CDO Person object alleviates the need to remember all of the various attribute names of User objects in Active Directory when performing the most routine tasks due to schema differences.
- Encodes and decodes data into Internet standard transfer formats, such as base64 and quoted-printable.
- Correlates meeting request responses into a master appointment in a user's calendar folder or a public folder.
- Works with both protocols and content. CDO can to submit an e-mail message to a local or remote SMTP/NNTP transport.
Both CDO and ADO rely directly on the Exchange OLE DB (ExOLEDB) provider to access data located in the Exchange store.
Note
You can use the Microsoft OLE DB Provider for Internet Publishing (MSDAIPP) with ADO to remotely access information in the Exchange store. Using CDO for Exchange 2000 Server (CDOEX) with the MSDAIPP provider is not supported.
In addition, the MSDAIPP provider relies on the WinInet application programming interface (API) to manage HTTP connections. The WinInet API is not supported in middle-tier or server-side applications. Therefore, you should not use MSDAIPP in middle-tier or server-side applications.
CDO objects can also be bound to ADO objects directly; this increases 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 to the ADO object. Therefore, you need only one session when you process items by using both CDO and ADO.