Drawbacks of Using the ADO Cursor Engine

[Previous] [Next]

I won't try to tell you that the ADO Cursor Engine doesn't have drawbacks or limitations. I've yet to see a set of RAD libraries that doesn't. However, I won't give you the laundry list of these disadvantages here. For the most part, I'll point them out while discussing the Cursor Engine's features so that you're aware of them ahead of time, rather than finding out about them three quarters of the way through your development cycle.

Performance Issues

ADO is essentially an ad hoc query tool. It has to gather data about your database fields and tables in order to let you update the data. Most of the time, you already have the information that ADO is looking for. But ADO doesn't have interfaces to allow you to supply that information. As a result, the ADO Cursor Engine queries your database for that information.

For example, suppose you know the data type you've chosen for the BalanceDue field in your Customers table. You also know the fields that are part of that table's primary key. ADO gathers all this data each time you issue a query to generate an updatable Recordset with the ADO Cursor Engine. If you write your own code at the OLE DB or ODBC API level, you can avoid much of the overhead involved in an ad hoc query tool such as ADO. But generally, few applications benefit from the slight increase in performance, and few programmers have the requisite time and expertise to implement such code.

Limited Flexibility

During the ADO 2.0 development cycle, the program managers talked about using the GetString method of the Recordset object to build HTML tables. This sounded like a great idea to me, and I was surprised when I noticed the feature was dropped. (As of ADO 2.5, it still hasn't been added.) I later found out why—there was no way to implement the feature that would satisfy a significant percentage of users.

No matter how much flexibility the ADO development team considered putting into the feature, a fairly significant percentage of the users would inevitably say things like, "But I want the negative values to appear in a bold, red, italic font with a mauve background." There will always be limitations.

The ADO Cursor Engine is not infinitely flexible, but in most cases there's enough built-in flexibility to get the job done. I'll do my best to point out the limitations to you throughout the rest of the book. Since I don't list all the limitations here, you'll have to read on to learn about them as I discuss the major features and uncover the way in which many of them work.

Read-Only Fields

OK, scratch that, I will tell you about one specific limitation here. When the ADO Cursor Engine marks a field as read-only, there's no way you can programmatically modify that data in the Recordset.

Fields are usually marked as read-only for one of two reasons. First, an OLE DB provider might indicate that you're not allowed to update a particular field in a table. Since the ADO Cursor Engine will attempt to update the table based on changes you make to the associated Recordset, ADO won't allow you to update a field in the Recordset that corresponds to the read-only field in the table.

Second, ADO will not allow you to modify calculated fields in your Recordset. If you use the following query to generate a Recordset

 SELECT Au_ID, Au_FName + ' ' + Au_LName AS Author_Name FROM Authors 

you'll receive a field called Author_Name that's the concatenation of the Au_FName and Au_LName fields in the table. While you might be able to understand how to translate a change to this calculated field into appropriate values for the author's first and last name, the ADO Cursor Engine does not know how to accomplish this feat. As a result, this field is read-only in the Recordset.

If you retrieve a new timestamp value from your database and want to merge that data into an open Recordset, you're out of luck. It's unlikely that you'll run into such a situation in your application. However, there are similar scenarios in which you might find yourself coded into a corner if you don't know how the ADO Cursor Engine works. If you want to avoid such problems, read on—it builds character.