IN CHAPTER 6, WE DISCUSSED HOW, when, and why to construct a Recordset. Once you decide to create a Recordset to handle the rowset generated by your query, you will want to manipulate it. You'll think about binding it to data-aware controls (I suggest you don't), and think about sorting, filtering, and finding rows in the rowset (I suggest you do). When you paid up to seven some-odd megabytes of RAM for ADO, you mostly bought sophisticated Recordset management routines. Knowing how to use these routines efficiently and effectively will go a long way toward making your application a success.
I'm not a fan of data binding. IMHO, the expense of coding and managing data-bound controls seems to be higher than the benefits gained. Yes, data binding and Visual Basic's capability to manage it have improved in Visual Basic 6.0. But there are also fewer reasons to use it. While the data-bound (and unbound) controls have improved, the problems associated with connecting and result set management have not. For example, you don't need to data bind to fill a grid with rows from a Recordset—the MSHFlexGrid object's Recordset property can be set to any Recordset. Yes, bound controls can automatically update records based on changes in the control. You can do the same in one line of code in a grid click event. But as you'll see, trying to trap errors can be a serious drawback that can cripple any production application.
Sooner or later, you'll discover that when working with more sophisticated applications, you still have to code routines to validate the control cells before committing them to the Recordset—not to mention the error handlers needed regardless of the technique used. Beyond that, the bound control approach seems best suited for smaller table-based systems and not for procedure-based systems, where access to base tables is either limited or prohibited. I won't spend a lot of time on this. Other books and the documentation do a fine job of that. Data binding does not constitute a best practice.