Foreword

[Previous] [Next]

David and I had been swapping e-mail for several years when I was asked to write this foreword. Part of our daily routine involved hanging out on an internal Microsoft alias that deals with ADO issues—that's where we first met. All too often, it was David's sage advice that clarified an ADO issue I raised on this mailing list. Where David found the time to respond to the list given his other responsibilities is one of those mysteries of time and space that only Einstein could figure out.

When David's editors asked me to write this foreword, I was flattered but I knew that I would be working on my own ADO book for APress. I realized there might be a conflict of interest. Because David had selflessly provided so many great tips and techniques over the years, and because I had encouraged him to write a book in the first place, I couldn't turn him down. Now that I've read Programming ADO, I realize how well David's book complements my own books—both old and new.

I've been writing, teaching, and lecturing about Microsoft Visual Basic and data access since I started teaching Microsoft SQL Server at Microsoft University in 1988. Before that, I spent about a decade in the trenches, coding mainframe database systems and learning from other real-world developers. Because I'm no longer a front-line developer, I constantly have to communicate with developers and support people such as David to find out what's really working—and what's not. David's job brings him ear-to-ear—and often nose-to-nose—with some of the most difficult data access problems on the planet. He patiently listens to countless customers explain the symptoms of their problems. From these often-panicky accounts, David has to figure out what these customers have done to get ADO, ODBC, or OLE DB to behave (or misbehave) the way they're describing. I've found David's front-line experience invaluable—especially because David has a talent for guiding others to the "right" answer in a way that makes us feel smarter and better informed.

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.

Some of the mysteries David's book delves into involve how ADO works with the Web through RDS and with shape and hierarchical data providers. Many readers find these new subjects a little murky when they depend solely on the Microsoft documentation—I know I did. As ADO takes on more and more functionality, the trick is knowing how to make the best of its new technology without letting this technology get the best of us.

David's writing style is thorough and easy to follow and understand. And while he doesn't include as many jokes as I do, I'm sure his readers will find this book a great resource despite this shortcoming.

Bill Vaughn
January 2000



Programming ADO
Programming MicrosoftВ® ADO.NET 2.0 Core Reference
ISBN: B002ECEFQM
EAN: N/A
Year: 2000
Pages: 131
Authors: David Sceppa

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net