Where Are We and How Did We Get Here?

[Previous] [Next]

During the past five years, Microsoft has promoted Data Access Objects (DAO), and then Remote Data Objects (RDO), and now ActiveX Data Objects (ADO) as the primary data access technology for Visual Basic developers. It seems that Microsoft has been pushing a different data access technology with each successive version of Microsoft Visual Studio. Today, new versions of ADO are available on Microsoft's Web site and ship with other products and technologies, such as Microsoft Windows 2000, Microsoft Windows NT 4 Service Packs, Microsoft Internet Explorer versions 3 and later, Microsoft SQL Server 6.5 Service Pack 5 and SQL Server 7, Microsoft Office 2000, and even Microsoft Expedia Streets & Trips 2000.

One of the goals of ADO is to simplify data access. ADO is built upon some fairly complex technologies—OLE DB and ODBC (open database connectivity)—and is designed to allow you to programmatically access and modify data stored in a wide variety of databases. This broad reach is a departure from previous data access technologies. For the sake of comparison, let's take a quick glance at ADO's predecessors: DAO and RDO.

Data Access Objects

DAO was originally designed to interact with Microsoft Access databases. Although you can use DAO to access SQL Server and Oracle databases, many developers complain about DAO's performance with these large database systems. Others complain that DAO doesn't permit programmers to access some of the richer, more powerful features of SQL Server and Oracle, such as output and return parameters on stored procedures.

One of my coworkers likes to say that using DAO to work with an Oracle database is like performing brain surgery on yourself…without anesthetics…while wearing oven mitts. Extreme? Yes—but he does have a point. DAO is tuned to work with desktop databases, not client/server databases. Frustrated by DAO's performance and access limitations, developers who wanted to work with SQL Server and Oracle databases generally sought other options.

Remote Data Objects

Microsoft provided another option in RDO, which originally released with Visual Basic 4 Enterprise Edition. RDO's object model closely resembles the hierarchy of structures in the ODBC API. Programmers found that RDO provided much faster access to client/server database systems, such as SQL Server and Oracle, than DAO did. Although those familiar with the ODBC API quickly learned how to work with the RDO object model, developers lacking experience with that API, such as those who had been using DAO, found the RDO technology difficult to use.

The object model itself wasn't the problem for most programmers learning RDO: the nuances inherited from the ODBC API posed the greatest obstacles. Suddenly, programmers had to bone up on cursors and bookmarks. They had to learn many of the ins and outs of specific database systems. Does the error message "The connection is busy with results from another hstmt" ring any bells out there? If you try to do the impossible on an ODBC connection to your database, RDO won't save you. Instead, you'll get that error. DAO hid the problem from you by automatically creating another connection to your database to perform the action you requested.

Another challenge that RDO posed for programmers accustomed to writing DAO code was that RDO lacked many of DAO's features, such as sorting, searching, and filtering. Other DAO functionality unavailable in the RDO world includes data definition language (DDL) interfaces to ODBC API functions such as CreateTable and CreateField.

Best of Both Worlds: ActiveX Data Objects

Programmers clamored for a data access technology that combined the simplicity and relative ease of use of DAO with the speed, power, and control of RDO. Initially introduced as part of the Microsoft Internet Information Server 3 package, ADO was intended to be all things to all people. Of course, such lofty goals are rarely fulfilled.

While the initial release of ADO lacked many of RDO's features, I believe that ADO 2.0 offered comparable functionality. Certain RDO features, such as mixed cursors, have yet to be implemented in ADO, but these features are few and far between. In fact, I'm at a loss to name a single significant feature available in RDO that was not available in ADO 2.0 in one form or another. (I'm sure someone will tell me otherwise; a great way to find such features is to make a statement like that in a book like this.)

With the release of version 2.1, ADO and its supporting libraries began offering nearly all features available in DAO. DDL libraries were added to ADO in version 2.1 to provide functionality similar to functions available with DAO, such as CreateTable, CreateField, and CreateIndex. Microsoft Jet and Replication Objects (JRO) in ADO 2.1 offers much of the Jet-specific functionality available via the DBEngine object in DAO. ADO 2.1 also added functionality to simplify the retrieval of newly generated identity values. ADO 2.5 adds no new functionality to more closely match the capabilities of DAO and RDO, because perhaps the only place where ADO lags behind DAO is in its searching and filtering capabilities.

So ADO has most of the functionality of RDO and DAO as well as many helpful features not available in previous data access technologies. Great. Why, then, can't I get a moment's peace at work? Why are programmers having problems building applications with ADO?

Difficulties Using ADO

First of all, ADO is still a fairly new technology. The Microsoft Data Access SDK documentation that shipped with Visual Studio 6 (as part of MSDN Library Visual Studio 6) was for many programmers the primary source of information about ADO. Unfortunately, the information in the Data Access SDK is more reference-based than instructive—lacking samples, best practice information, and in-depth discussions about how the technology works.

One of the many reasons for the lack of detail in the documentation is that products are being released on Internet time. The team developing the data access components has been in "ship mode" for the past two years. Since these components are now included with many different Microsoft products—Internet Information Server 3 and 4, Internet Information Services 5, Visual Studio 6, SQL Server 7, Internet Explorer 4 and 5, Office 2000, and Windows 2000—the developers don't always have control over their own ship schedule. As with most products and teams under constant stress, something has to give, and in this case it's been the documentation. The development team has been operating in "ship now, document later" mode for too long.

Another reason programmers are having problems with ADO lies in its flexibility. While this flexibility is generally a strength, it has posed a challenge to the documentation team and been a source of confusion to programmers, because there is no "one way" to do things. For example, ADO offers many different ways to get data from your database into a Recordset object, yet much of the early documentation focused on only one of those methods; unfortunately, that method returned read-only data, not data that could be modified. For anyone who still hasn't been able to get an updatable Recordset object—we'll cover that topic in Chapter 4.

Lastly, building a multiuser database application with ADO, or with any other data access technology, isn't easy. Although tools such as Visual Basic 6 Data Environment Designer can save you a great deal of time, you should be wary of anyone who tells you that you can build a multiuser database application without having to write any code.

In many ways, ADO behaves like DAO in that it contains features that hide certain complexities from the programmer. I mentioned an RDO error message earlier—"The connection is busy with results from another hstmt"—that occurs when you try to use a connection that's already busy. ADO simplifies the programmer's task by establishing another connection rather than returning an error such as that. However, it's important to know what's going on behind the scenes and why: you wouldn't want to unwittingly create an application that establishes 8 or 10 connections per instance of your application. This book will discuss this and other such features in depth so that you don't stumble across them accidentally or employ them inappropriately.



Programming ADO
Programming MicrosoftВ® ADO.NET 2.0 Core Reference
ISBN: B002ECEFQM
EAN: N/A
Year: 2000
Pages: 131
Authors: David Sceppa

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net