Conclusion

[Previous] [Next]

So here are our conclusions regarding hierarchical recordsets in Visual Basic 6.0 with ADO:

• For two-tier applications, in which you can stay connected to the database, relate parents to one or more parameters in the child command. Such a hierarchical recordset seldom gives you more child records than the quantity you really need.
• For three-tier applications, in which you must disconnect the recordset from the database to be able to move it over the network, relate parent and child recordsets to each other using the field-to-field method. To avoid getting more records than you need in your child recordset, use the special kind of filtering we have described in this chapter.
• Manage updates by connecting parent and children separately to the database, and by making sure you always do updates in the correct order according to the nature of the update and your business rules. Don't count on the UpdateBatch command, issued on the parent recordset, also to work on the child recordsets.
• Don't trust successful in-process tests also to work cross-process. This statement is valid for just about everything; it's certainly valid for hierarchical recordsets.

Finally, you don't have to use hierarchical recordsets if you don't want to. As an alternative, you can create two or more recordsets separately and package them together in a Variant array. This isn't as convenient as using a hierarchical recordset, but the number of anomalies you need to handle is probably lower. The choice is yours!