Benefits of Using the ADO Cursor Engine

[Previous] [Next]

Some of the greatest advantages of using the ADO Cursor Engine are that you can save time, simplify your code, and write code that is database independent.

Saving Time

The biggest benefit of using the ADO Cursor Engine is the time you can save by leveraging the libraries created by the ADO development team.

If you're an accomplished programmer, there is nothing that the ADO Cursor Engine does that you can't do yourself—given enough time. But that's the catch. How many programmers have enough time to develop such a flexible, powerful set of libraries?

Notice that I said "accomplished programmer." As you'll see in the upcoming chapters, most of the features of the ADO Cursor Engine are nontrivial. While they're not perfect, they are rather well thought out. It takes a great deal of planning and expertise to develop such a helpful set of features. I fancy myself a decent programmer, and I know better than to criticize developers in the Microsoft Data Access Group. They could probably do my job. But I don't think I could handle theirs.

While I would never tell a programmer not to try to develop a set of libraries similar to the ADO Cursor Engine, I'd wish him luck and hope he has a backup plan or an impressive résumé.

Simplifying Your Code

Using the ADO Cursor Engine can also simplify your code. Some of the most impressive developers I've worked with, both inside and outside of Microsoft, write code that is disorganized and difficult to follow. The biggest drawback to such spaghetti code—code that works but which no one but its creator can understand—is that it can become impossible to maintain.

As a support professional, I spend a good portion of my time reviewing code written by customers and coworkers. You can follow another programmer's code much more easily if the programmer relies on components that you're already familiar with, such as those of the ADO Cursor Engine.

Writing Database-Independent Code

Have you ever developed an application to interact with an Access database only to discover later that the plans have changed? Perhaps someone within your company has decided that the next version of your application must instead work with a client/server database such as SQL Server, Oracle, Sybase, Informix, or DB2.

If your application relies on features available in the Access driver or provider's server-side cursors, you'll have a lot of code to rewrite if your new database doesn't expose server-side cursors or has functionality that's different from that of Access databases. If you initially designed your application to use the ADO Cursor Engine, however, you'll be able to use most of your code to communicate with the new type of database.

The features of the ADO Cursor Engine are designed to be database independent, allowing you to use the same code against any database.