I CAN'T TELL YOU HOW many people have asked when the next edition of Hitchhiker's Guide to Visual Basic and SQL Server is going to be written. So much of the technology has evolved since it was written that I can certainly see the need to update this tome. Since Visual Basic 6.0 shipped, ADO has changed at least eight times, so many of the examples and explanations in the 6th edition of the Guide are somewhat dated. However, Visual Basic 7.0 is not nearly done, so it's really too early to update the Guide.
When given an opportunity to write a book for Apress, though, I realized this was a perfect opportunity to focus on what has changed most—ADO. I could bring my readers up to speed on the newest features and techniques, without worrying about how Visual Basic will look in the future. But there are a lot of books out there on ADO programming. What I needed was a focus that would most appeal to you, the front-line, in-the-trenches developer. Thus ADO Examples and Best Practices was born.
Some of you will be migrating from other programming interfaces, such as Data Access Objects (DAO) or Remote Data Objects (RDO). On occasion, I make a passing comment about how to make this transition easier, but I don't dwell on those issues. Some of you will be transitioning (whether you want to or not) from an earlier version of ADO, and this book's for you.
Obviously, ADO Examples and Best Practices focuses on ActiveX Data Objects (ADO) version 2.5, but in a way that reflects what countless developers, trainers, and support engineers have passed on to me over the years. Yes, it's these people that provide the pathway to what I write in these books. For the last 14 years, I have made a living by writing, training, and documenting code—not by writing or supporting applications, as I did the first 12 years of my career. Because of this, I have to constantly work with others who do. When I can, I help them solve problems encountered in the "real world," but just as often the developer community provides me with innovative and tried-and-true ways of using the tools. These examples and "best practices" are techniques discussed, refined, and used by hundreds or thousands of the most talented developers in the world. And yes, many of the ideas come from "international" developers outside the USA. While some of the ideas come from inside Microsoft, where I am bound to a certain level of secrecy, many come from off campus, where developers often have to make do with what the folks on campus produce and shove out the door. I also regularly communicate with the product managers, developers, and product support teams here at Microsoft, who try to get the tools and interfaces to work better—based on your requests (and mine).
ADO Examples and Best Practices goes where the Guide did not—into the realm of the Web. It has fairly extensive discussions of how to best use ADO in ActiveX Server Pages (ASPs), as well as browser pages written in Visual Basic Script. While the book covers most of the new ADO 2.5 features, it also discusses other technologies such as XML and MSXML where it makes sense. Although this book is not a "programmer's reference," it does detail many of the individual objects, properties, and methods as I did in the Guide. Despite the Web hype out there, this book fully discusses client/server and middle-tier, along with Webbased ADO architectures, and the code development, deployment, and performance analysis issues associated with each paradigm.
Performance is a regular thread in ADO Examples and Best Practices. But to me, "performance" means more than writing code that runs fast. It means writing code that helps developers work more efficiently—write more solutions in less time and at a lower cost, not necessarily more code. This is especially important for developers working in teams. All too often the programs we write today were originally designed and implemented by others—or at least parts of them. This means that you have to deal with other developer's designs, techniques, and documentation—assuming the latter exists. And others have to deal with what you write. We are constantly challenged to create code that can be passed on to others to integrate, support, or debug. There are a lot of techniques you can use to make this process easy—easy for you and for the people who have to deal with what you write.
But this process requires what many programming shops, even those at Microsoft, don't have: discipline. No, I'm not talking about having a person walking the halls in leather and studs, cracking a whip (or at least I hope not)! I'm talking about establishing standards within the organization and sticking to them. It means writing spec, and coding to spec. It means curbing your desire to code outside the spec because you know how to do something better than the toads who created the spec. That might be the case, but unless you get your coworkers and managers to help change the spec, what you're creating is counterproductive. If you don't code to spec, your innovative code is not likely to work with other developers' code—now or in the future. Discipline also means curbing your arrogance. Deciding that the consumer of your code can take it or lump it is hardly a productive attitude—but it is not an uncommon mindset in some shops. Of course, if you are paid by the line, you are free to ignore these suggestions. Just don't look for repeat business.
We'll also look at ways to reduce COM overhead, reduce your applications' load time, and to better utilize the LAN, WAN, and Web, as well as RAM, disk space, and other system resources. We'll look at how to write programs that other developers can understand and support—without you having to interrupt that Saturday afternoon barbecue. (That's a barbecued SQL Server.)