ADO: ActiveX Data Objects

ADO and COM: Language Independence

Microsoft’s Component Object Model, better known as COM, is a mature technology that offers universal access to components, regardless of the language in which they were programmed. This is the backbone that allows ADO, through OLE DB, to be so versatile. To understand how COM allows ADO to be language-independent, you must first understand what COM is and what it achieves.

COM

COM is technology specification for writing software components that interact through a standard interface. The COM specification is strictly a binary specification. This guarantees that the language in which a COM object is developed has absolutely no importance once the object is compiled, as long as its adheres to the binary specification.

The COM specification sets rules for creating and managing component objects. This specification guarantees that all COM objects are compatible and that they expose a minimal set of interfaces. These interfaces allow COM objects to communicate with each other whether they are on the same machine or supported by networks. Since the COM specification relies on binary compatibility, COM works across heterogeneous networks. In other words, COM objects can run on any machine, even without the Windows operating system.

A particular type of COM implementation is OLE Automation, or simply Automation. Automation is a standard way for COM objects to expose their functionality to software products, development languages, and even scripting languages. The use of Automation allows applications to actually manipulate other applications through the exposed features and functionality of the latter’s COM objects. Automation allows two applications to communicate with each other.

An example of this type of manipulation is a Visual Basic add-in. Visual Basic exposes an object model through the COM technology to any other component that wishes to interact with it. You can create an add-in for Visual Basic that works seamlessly with the product, through the use of Visual Basic’s exposed features. As a matter of fact, many of Microsoft’s products expose their features through COM, including the Microsoft Office family of products. Microsoft Word, for example, exposes its functionality through COM and allows itself to be manipulated through scripting with VBA (Visual Basic for Applications).

When a COM object is exposed through OLE Automation, that object is then called an ActiveX object or an ActiveX server. The application or tool that manipulates the ActiveX object is called an ActiveX client.

ADO and COM

As a COM technology, ADO has the ability to communicate with any data source that provides an OLE DB interface. ADO and OLE DB share the same backbone -- COM. Figure 1-6 shows COM at work with ADO and OLE DB. When ADO communicates with a data provider at the simplest level, two COM objects are exchanging information, regardless of the connection between them.

Figure 1-6. ADO and COM

Also, COM has the ability to send events or notifications to other COM objects. This capability is used in ADO, as we will see later on when we execute queries. We have the ability, through ADO, OLE DB, and finally COM, to send a request for a selection of records through SQL and then to be notified when it has completed processing.

What is even better is that COM has been around for a long time, has gained the respect of application and tools developers, has a proven track record, and is supported by Microsoft. COM’s architecture does not change between programming languages or operating systems; thus, neither does ADO.

COM objects are easily distributed. They have the ability to communicate across machines and enterprises. This advantage is embraced with ADO through RDS, or Remote Data Service, which I will be talking about in Chapter 11.

As you can see from this very limited introduction to COM, ADO stands upon OLE DB, which relies heavily on COM to communicate with other COM objects. This can do nothing but benefit us as developers, because it enables communication with objects that aren’t necessarily written in the same language.^[1]

---

^[1] For more information, see Inside COM by Dale Rogerson (Microsoft Press, 1997).