Other Sources for ActiveX Controls

There are a number of places you can get ActiveX controls. The trick is finding ActiveX controls:

That work with Access
That are data bound and require as little, if any, VBA programming

To be honest, in my experience, the majority of the ActiveX controls available do require some programming. The good news is that the controls usually come with sample code. Here are some sources for ActiveX controls:

Microsoft Corporation: The Microsoft Office Developer Edition has a number of controls, including Windows common controls for things such as file opening and saving.
DBI Technologies: These guys have a number of products that are ActiveX controls, including Component Suite 4.0, which has over 50 controls. They also have scheduling and PIM ActiveX controls. Although some coding is required for these, they have great sample applications.
FMS Inc.: Their product, called Total Access Components, contains 27 ActiveX controls. They can be reached at www.fmsinc.com.

What Is ADO?

ActiveX Data Objects, or ADO is an object model that is a successor to DAO and is intended to replace DAO. Of course, the arrival of ADO raises the question of whether to redo existing DAO applications in ADO, as well as whether to write new applications in ADO.
As to the former, I cannot see any immediate need to do so unless the application would benefit by some new feature of ADO. One possibility is that ADO may provide superior performance, but this is an ad hoc issue that will require experimentation in each situation. As to the latter, this decision is somewhat of a moving target. While DAO is more established and has proven to be reliable and stable, ADO is Microsoft's current wave of the future. For instance, the new VB6 DataBinding object model is just a frontend for an OLE DB data client and is designed to use ADO. In order to keep up with Microsoft's latest technologies clearly a desirable goal we will need to get on the ADO bandwagon. We can only hope that Microsoft will offer us other good reasons to join this bandwagon.
Actually, ADO is the immediate successor to Remote Data Objects (RDO), which is, in turn, the immediate successor to DAO. Since RDO did not get much first-string playing time, we will not discuss it in this book. My plan is to discuss the terminology related to ADO and its underlying technology, called OLE DB. Then we will look at the ADO object model and do a few examples, such as connecting to a Jet database, an Excel spreadsheet, and a text file. This will give you a solid foundation in ADO and OLE DB, certainly enough to understand the documentation (such as it is) and dig more deeply if the need arises.
It appears from the documentation that I have seen (from Microsoft and others) that most writers feel that the most important use of ADO is to connect to an SQL Server data provider. However, in my consulting practice, I seldom encounter SQL Server (or perhaps I just unconsciously avoid it). Much more often, I encounter the need to connect to an Excel spreadsheet, for instance. A great many business clients like to do database management in Excel, probably because they are familiar with that application, since they use it for financial analysis (which is its intended purpose). It seems that it is only the VBA consultant, and not those who hire her, who appreciates how limited Excel is when it comes to database management!