Programming ADO is much more than an ADO programmer's reference. Any serious developer will tell you that a thorough understanding of ADO requires more than just listing object names and their properties. ADO is a complex COM front end on an even more complex OLE DB data access layer connecting to an ever-growing number of providers. Understanding how these objects, interfaces, and providers interact is essential. While one really has to know how ADO behaves when things work as expected, it's even more important to know how ADO behaves (or misbehaves) when things go wrong. For example, error handling, and the messages ADO returns when "stuff" happens, is not one of ADO's most understandable aspects. David's explanation of ADO error management implementation, especially when updating Recordsets, is complete and easy to understand. I'm of the opinion that robust, comprehensive, and insightful error handling is what makes production programs successful. David's "What now?" approach clarifies a number of situations commonly encountered by those trying to code ADO. I also like David's "questions that should be asked more frequently" sections. These brief question/answer dialogues clarify a number of interesting points in a way that makes learning ADO far easier. David has compiled an invaluable, comprehensive guide for developers trying to get a handle on how to best create successful Visual Basic data access applications and components.

It's not only good or "right" code that makes successful applications—it's also good, well-planned designs. When we write about using low-level programming interfaces such as ADO, we must focus on using the practices that result in solid, scalable, and supportable applications—not necessarily applications that are easy to code. But without a clear and workable design, this process can be frustrating for developers and users alike. For example, I'm of the opinion that stored procedures can and do play an important role in scalable, high-performance SQL Server applications. While stored procedures are not necessarily easy to design, code, or access from ADO, it's important that developers understand how to access them from their applications and components. David's approach to design includes a comprehensive treatment of stored procedures: he provides a healthy section on the subject.