ADO: ActiveX Data Objects

When to Use ADO

ADO is language-independent, as discussed earlier. This means that no matter which language you are developing with -- Visual Basic, VBScript, Visual Basic for Applications (VBA), Visual C++, Visual J++, or JavaScript -- the development interface is identical. This allows developers to become familiar with the technology itself, instead of worrying about learning a half-dozen different programming syntaxes for that technology. I suggest that you use ADO whenever your application fits into any or all of the following categories:

• Your application accesses or may later need to access more than one data source.

• Your application accesses or may later need to access data sources other than ISAM or ODBC databases.

• Your application spans or may later span a heterogeneous network.

• Your application uses or may later use multiple languages.

If your application needs to access more than one type of data source, then you should consider integrating ADO technology into your application. For instance, if you were designing an application that had to search Word documents, email messages, and a SQL Server database for keywords and then to show related information based on that query, ADO is the best choice. With ADO, you can create a component to search all three of these data sources using identical code, saving you time in development, as well as in maintenance and upkeep. This choice also provides the option of adding a fourth data source to your application at some later time with little or no additional overhead in development.

If your application may access data sources other than conventional ISAM or ODBC databases, you should use ADO. With ADO, you can search through an Excel worksheet just as if you were searching through email messages. If you use some other technology besides ADO, you must not only code two different components, one for each data source, but you also need to learn that other technology. In this case, you would have to research MAPI API calls, as well as Word document file structures. And then what happens when Word comes out with a new version? Or what about when more APIs are added to MAPI? You could easily ignore these until your application becomes so outdated that it renders itself useless. With ADO, you simply use the data service providers supplied by Microsoft for both Excel and Word so that the ability to access and manipulate these data sources are exposed identically through ADO.

If your application has or may spread across a heterogeneous network, such as the Internet or your corporate intranet, you should use ADO. For instance, consider an application that is deployed from your company’s server to each employee. This application might access data stored on a mainframe containing legacy data. From this point, ADO serves as a driver to access data on this mainframe platform. This alone would save you valuable time and effort, because in order to access the mainframe data source by some other means, you would have to write custom drivers, or even worse, spend a fortune on a third-party tool that might not do everything that you want. Even the client side would benefit from ADO. Suppose you have employees that don’t have a Windows machine in front of them, but who need access to the same data that someone running Windows has. Other employees might use a Sun workstation, for instance. As long as they use a browser that supports ActiveX technology, such as Internet Explorer, it is as if they are running the same application. In addition, if your application is prone to updates or fixes, by deploying it over the network using Internet Information Server (IIS) along with Active Server Pages (ASP), you can automatically (and transparently) update the client’s version of the application each time it changes.

If your application uses multiple languages, especially if they are in the same tier of an n-tier client/server architecture, then ADO is the best choice. If you are the only developer of an application, or even if there are a handful of developers, then by sticking to a language-independent data-access technique, you eliminate the need to know multiple implementations of the same technology. For instance, if your application has business-rule components that update the data source, query the data source, or delete from the data source, it is very likely in today’s development environments, that each component could be written in a completely different language. By fully understanding ADO, you can make the best use of the same technology in each of these languages.

On the other hand, there are a few cases in which you shouldn’t use ADO. If your application falls into any of the following categories, an alternative method of data access might be preferable:

• Your application is already too far along to redesign and currently does not support business components for data access.

• Your application needs to read in only text data from a flat file, which cannot be broken down into logical rowsets.

• Your application saves data in your own format, and you do not wish to offer others access to your data through OLE DB.

If your application is already under development, it’s probably too far along to turn back now. If it does not support business components for data access, you might not have a choice in converting to ADO. If the data-access technology, whether DAO, RDO, or something else, has not been placed within designed business components to handle the data access, you would most likely spend more time rewriting your application to support ADO than is justified.

By using business components in your applications, you can alter a few areas of code to achieve a widespread result. In this case, if your application had a component to read from your data source and a component to write to your data source, your application would call the business components rather than calling DAO, RDO, or even ADO directly. When a new technology such as ADO comes along, you simply change the two components, as opposed to changing every location in your application that now calls the components.

If your application will read in only text data from a flat file, which cannot be broken into logical rowsets of data, you may be better off using the Visual Basic Open statement, or the file-access statement equivalent for the language you are developing in. For instance, if your application displays a readme text file in a registration screen, can you imagine opening up a database and using the rowset methodology on streamed text? You should use the Open statement, if you’re using Visual Basic, to read in the readme text file yourself. ADO is overkill in a situation like this.

If your application is going to save state information or other data and will not allow others to view this data through OLE DB or any other conventional database technology (DAO, RDO, ODBC API, or ADO), you may not want ADO. To ensure the security of your data, it would be wise for you to write your own functions for storing and retrieving information from an encrypted binary file. This binary file would have a structure that only you, as the developer, would be aware of, as opposed to the structure of an OLE DB-enabled file, which can be read at runtime. Of course, even though nobody knows the structure of your binary file, people are smart -- they could figure it out. To ensure that people can’t see the data, you must encrypt it. For instance, you might want to write an application that does your taxes for you (and pretend that nobody else ever wrote a program like this before, so that we have a reason to do it now). After a year of entering financial data, the user can automatically print tax reports and forms that can be sent the government. The data that is entered all year long obviously has to be saved somewhere, but the question is where. My suggestion in this case would be to create a binary file in your own data structure, hiding that structure from the outside world. This file will hold personal financial information that you really don’t want other people to have access to. With ADO, you would be exposing it to the world, whether you wanted to or not.