Access 2003 VBA Programmer's Reference (Paperback)

I do not disagree that the book is comprehensive as the description and the reviews point out. It discusses subjects that are wide-ranging and, I am certain, very important to many readers.

My contention is that the book is not organized in such a manner as to allow a less experienced user to get at what he wants. I think books like these need to better indicate for whom they are written. The foreward talks about it being for those who have been using Access for some time and are just beginning to jump into the world of code. I have had a reasonable amount of experience with Access, relational databases and electronic spreadsheets. I have a decent understanding of programming although only little expereince with object oriented programming.I feel that I understand Access sufficiently well that I have a base upon which to add the VBA skills. I really don't believe that the book is written for such a person.

My opinion of the shortcomings follow.

I believe the most important component of a reference source is the index. In this case the index is 24 pages with 100 entries on each. The frustration I faced in trying to answer my questions through the index, and table of contents was as bad or worse than trying to use Microsoft help screens or on-line resources.

I do not understand the organization of the book. It does not seem to follow a path from broad to narrow or any other progression that makes intuitive sense. I know this is acceptable in a reference but only, I would say, if there was a sufficient index.

The general execution of the book was also inferior. I was frequently distracted by grammar errors such as the wrong word (eg "than" instead of "that") and even typos. The figures and tables were numbered but not titled and in at least one case was misreferenced from the text. I found myself really in need of a diagram in many cases but there were none to be found. The car analogy used to explain Object Oriented Programming was not clear and I think possibley incorrect. The analogy describes "Press" as a method of the "Gas Pedal" object when it seems to me to be more like an event triggered by the user. I am not saying that I am necessarily right or the authors definitely wrong. I'm just saying that the analogy was ineffective. Again, I would have loved (and expected) a diagram or some representation that would explain this difficult concept.

I want to say that in the end I did find the elusive answer to my question although just by chance. I think this will illustrate my frustration with this book. I wanted to know how to automate the import of a TXT file. I had searched on-line help and 2 other Access books as well as this book but could not find the answer. I finally was skimming through the methods of the DoCmd Object in Appendix E (The Access Object Model) and happened on the DoMenuItem method (page 750.) The description of this method explained that it executes the specified menu item but that it was a legacy from Access 97 that had been replaced by the RunCommand method in later version of Access. I then flipped forward in the same appendix to the RunCommand Method Arguments section (page 793) which started with this comment: "One of the easiest ways to perform a variety of functions in Microsoft Access is through use of the RunCommand Method." I thought that if it was so easy, then why doesn't somebody include it in their discussion of VBA. (I don't know if this book does so because the only reference to the RunCommand in the index is to the Appendix pages noted above. There are no references to the DoCmd or menus in the index.)

When I found this discussion, I knew that I had answered my question but I still had more errors to deal with. The section was entitled RunCommand Method Arguments but the verbage that preceded the table stated "The RunCommnad takes a single argument, the acCommand constant. All of the available acCommand constants are listed in the following table." The column in the table that follows is entitled "Argument." I know that constants can be arguments but don't these constants relate to the acCommand which is the only argument of the RunCommand? I know this is picky (and I feel more than a little self-conscious for exposing my ignorance) but doesn't a book about language need to be precise and consistent in their use of terms?

I would also ask what the value is of this (the RunCommand Methods Arguments) table. It simply lists the constants (Arguments [?]) This information is available and more easily accessible in on-line help. The inclusion of this table (and possibley others) may make the reference more complete but does not necessarily make it more valuable. At the risk of beating a dead horse, I feel this table illustrates another shortcoming of this text in that it isn't even organized very well. The 9 page table has two columns that list the constants alphabetically. The first column starts on page 793 with acCmdAboutMicrosoft and finishes on page 802 with AcCmdPivotChartDrillInto. The list continues in column 2 back on page 793. I know this is confusing but so is the book.

I have no doubt that the authors of this book are extremely knowledgeable (and even really good and helpful people.) I would love to know what they know. That is why I bought this book. I can't imagine the difficulty in trying to organize and explain such a large and complex model but that is what they have attempted to do. I would love to see this book reworked and represented in a better way because I think think it contains a lot of good information. I just don't think enough consideration was given the user or enough care was taken in the execution.