Category list

Passing Recordsets Across Process Boundaries

[Previous] [Next]

Passing Recordsets Across Process Boundaries

You've probably heard that two-tiered client/server applications are pass and that Component Services (Microsoft Transaction Server) and Microsoft Internet Information Services (IIS) are now the tools of choice for building large, multiuser applications. Maybe you know a little bit about the inner workings of COM as well as its distributed counterpart , DCOM, but you're not sure how to proceed with your development.

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 fairly advanced topic in COM, and while I cover many of the inner workings of ADO, the inner workings of COM are beyond the scope of this book. I strongly recommend picking up a book or two on the topic such as Understanding ActiveX and OLE, by David Chappell [Microsoft Press, 1996], or Inside COM, by Dale Rogerson [Microsoft Press, 1997].

[Previous] [Next]

Remote Data Service

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.

[Previous] [ Next ]

Benefits of Using the ADO Cursor Engine

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 rsum.

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.