Wayne Wallace and Peter Vogel Silver Collection
This month, Wayne Wallace and Peter Vogel put their heads together to give you a list of books that you can't write applications without.
We both get asked quite frequently what books are useful to an Access programmer. This article is our joint answer. Take this list with some skepticism—it is, essentially, an arbitrary list based on what we keep by our desks. We certainly haven't read every book that's relevant, and many of our prejudices probably just reflect our cumulative age (over 90, altogether). We refer to many of these books out of habit, not because they're necessarily the best books on the topic. It's just that the first editions of these books were there when we needed them. You'll notice, for instance, that many of the contributors to this newsletter have books that don't appear on this list (Rick Dobson and Russell Sinclair leap to mind, for instance). You know how good those writers are, and you can make a reasonable assumption about their books. We've read their books and recommend them highly. But for this article, we're concentrating on the books that we couldn't live without, rather than just the really good ones.
We'll start with programming Access. If you don't have a copy, for whatever version of Access that you're using, of one or both volumes of the Access Developer's Handbook by Paul Litwin, Ken Getz, and Mike Gunderloy (Figure 1), then you're coding with one hand tied behind your back. Cumulatively, these three authors know more about Access than anyone else. Over and above the code advice and instruction, the book has, in total, more code than any other repository. It's just a great resource.
However, this area—programming Access—has more good books than any other category. We started to list the books that we liked but realized that there were too many different kinds of books to be able to recommend any one. There are, after all, introductory books, advanced books, cookbooks, sample solutions books, and more. One of the benefits of working with a tool as popular as Access is that there's a book on almost every topic. There's even a book on using Access to work with PLCs (Program Logic Controllers). You'll need to decide what book you'll need. Having said all that, you need the Access Developer's Handbook.
Coding is good, but data design is better. If you get the database design right, your coding will go much better. Peter likes Database Design for Mere Mortals: A Hands-on Guide to Relational Database Design by Michael Hernandez (Figure 2). Michael takes a different approach than the traditional route that goes through the stages of normalization. Wayne liked Rebecca Riordan's Designing Relational Database Systems, but it's out of print. Lately he's been recommending Inside Relational Databases by Mike Whitehorn and Bill Marklyn. Wayne likes the way that the authors combine practical "this is how you do it" kind of information with good theoretical underpinnings.
If you're going to work with a relational database, you're going to need to know Structured Query Language. A good introductory book is The Practical SQL Handbook: Using Structured Query Language by Judith S. Bowman. The book begins with a discussion of database design that may make our recommendations on database design unnecessary. If you're feeling like you want more, Joe Celko's SQL for Smarties: Advanced SQL Programming explores the more advanced and esoteric areas of SQL.
DAO works great, but if you're not using ADO you're missing some real opportunities. The best book to get started with, in our opinion, is Rob Macdonald's Serious ADO: Universal Data Access with Visual Basic. It covers everything you'd ever need to know about programming with ADO. A good follow-up is Bill Vaughn's ADO.NET and ADO Examples and Best Practices for VB Programmers (Figure 3). This is an extension of Bill's earlier book on ADO best practices. This isn't a comprehensive or introductory book, but it's advice from a master.
There are some higher-order issues to discuss that should be addressed before you start writing code. We both think, as Access developers, that we're insulated from many decisions about user interface design. There's so much that Access takes care of in the area of form design that most user interface errors simply can't be made by Access developers. However, GUI Bloopers: Don'ts and Dos for Software Developers and Web Designers by Jeff Johnson has a lot to say on the subject. And making fun of other people's programs is always enjoyable.
If you're ready for a challenge, a very theoretical (and high-level) discussion of the future of relational database design is in Foundation for Future Database Systems: The Third Manifesto by C. J. Date and Hugh Darwen. As near as we can tell (as we said, the book is very high-level), the authors want to claim that no further advances can be made in database design (take that, object-oriented database vendors). Relational database design, the authors claim, isn't just a way to manage data, it represents the ultimate and final form for all data storage (with the addition of user-defined datatypes).
We should probably recommend some books on system design and project management, but we couldn't come to any agreement in this area. The only book that we agreed that we both like is Exploring Requirements: Quality Before Design by Donald C. Gause and Gerald M. Weinberg. Gerry Weinberg is something of a genius and a seminal figure in computing. Exploring Requirements addresses the key issue in application design: finding out what needs to be done. The book also makes the point that one of the key results of the requirements process is a unified team made up of the users and the application developers.
Since it's so important to know what's going on before you start to write code, Peter recommends two books that aren't strictly about Access. Actually, they aren't about Access at all but are about how to sift through the evidence available to you. The first book is Eyewitness Testimony by Elizabeth Loftus. This book gathers together the available research (along with the author's own) on just how reliable eyewitness reporting actually is. The short answer is, by the way, not very. Of course, you probably have numerous projects where you built what the users asked for and discovered that it didn't actually meet their needs. More important than making it clear how untrustworthy others are, the book makes you appropriately skeptical of your own observations.
The other book is Mute Evidence by Daniel Kagan and Ian Summers, which, unfortunately, is out of print but is available through sites like alibris.com and abebooks.com. Mute Evidence covers roughly the same territory as the Loftus book but in a very different way. The two authors are reporters who, in the 1970s, went out to investigate the reports of mutilated cattle ("mutes"). What they found was that people often report what they conclude from what they see, rather than what they see. In other words, you find out what people think is happening rather than what actually happened. Besides, this is the only book in our list with a real story, so it's a lot more fun to read than the others.
We're also both looking forward to Garry Robinson's upcoming book Real World Microsoft Access Database Protection and Security from Apress (Peter will see it first because he's supposed to write the foreword). Security is becoming an increasingly more important topic, and Access has its own special issues in this area. As near as we can tell, Garry's book is the first book-length coverage of the topic. What fun!