FOLKS, I APOLOGIZE FOR TAKING SO long to get to this point—but we're now ready to talk about data and result sets. We've covered a lot of ground up to this point, and we still have a long way to go. So, let's get started.
The Recordset object is the interface that ADO uses to expose rowsets. Not all result sets include rowsets, so your query might not include a rowset at all. Recordset objects are expensive to create, so if you have a choice, don't ask ADO to create one. However, when you do need to manage the rowset component of your query, the ADO Recordset is the most powerful object ADO has to bring to bear on your data access problem.
The Recordset discussion is spread over three chapters. This chapter discusses the how, when, and why of constructing a Recordset by walking you through the creation of the ADO Recordset object and providing a number of tips on how to make efficient use of the data source. I also discuss populating, navigating, and updating Recordsets, and try to clear up some of the confusion about locking—both page and row-level locking. In Chapter 7, I discuss how to manipulate the Recordset. There I focus on binding, sorting, filtering, and finding the rowset. In Chapter 8, I discuss marshaling Recordsets. No, not how to help them line up in neat rows, but how to move them from tier to tier.
The technique that you use to construct the Recordset object can have a significant impact on the performance and scalability of your application or component, whether it runs on a Windows desktop or on an IIS server down in the data center. As we saw in the chapter on ADO Command Objects, the syntax used to execute the query can also dramatically affect what gets executed on the server and what gets returned.