The ADO Cursor Engine makes passing Recordset objects across process boundaries amazingly simple. From a programming standpoint, you can treat the Recordset object almost like a standard data type, such as an integer.
We'll cover some of the basics of passing Recordset objects across process boundaries in Chapter 15. But be forewarned: this is a
As if passing a Recordset object and all of its contents across process boundaries using DCOM weren't impressive enough, the ADO Cursor Engine also helps you pass Recordsets across the Internet by means of HTTP (or HTTPS), using a set of libraries called Remote Data Service (RDS).
You can use RDS with any Microsoft Visual Studio language to develop applications that communicate over the Internet almost as easily as you can develop applications that communicate over your intranet. We'll cover RDS in more detail in Chapter 16.
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.
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
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 rsum.
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
As a support professional, I
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
The features of the ADO Cursor Engine are designed to be database independent, allowing you to use the same code against any database.