The Structure of this Book

We had a quandary while planning this book because we were initially unsure as to which direction we should take. Since the first edition of this book, for Access 95, the functionality and versatility of Access has grown significantly, as has the underlying power of Visual Basic for Applications ( VBA ). So - should we stick with the older features of Access in this 2002 edition, or radically change the structure to implement new features?

We decided to keep in focus the fact that this is a VBA book, and the fundamentals of VBA itself haven't changed greatly. Consequently, in this fourth edition of the book, we have carefully selected the aspects of Access 2002 that are relevant to beginning VBA development, and merged them with a reworking of our core content that is based upon feedback from industry sources, reviewers, and readers.

In other words, we are not going to cover every new feature of Access 2002 in this book and, while our coverage of VBA techniques will be very comprehensive, we are not going to mention every single method. Our goal is to teach you VBA programming from scratch and, for that reason, we're not interested in including anything that would complicate this task unnecessarily.

The decision that caused us the most difficulty concerned which data access method we should use. Access 2002 comes with ADO, although DAO is still available for use. Should we switch to ADO, or stick with the older, simpler DAO technology? You might think that the obvious solution would be to use the newest, but this is not necessarily the case because of the different ways that Access 2002 can be used.

Access is used in two main ways:

• As a standalone database. This is the most common usage and programming Access 2002 with VBA in this scenario remains largely unchanged. The new data-access method, ADO, can be used here but DAO still gives better performance.

• As the front-end to a client-server database. Although this was possible in previous versions of Access, it's been taken a step further with Access 2002 to provide a better client-server environment. Only ADO works in this situation.

We'll examine the performance benefits of working with DAO in the standalone situation in later chapters but, for now, it's worth pointing out that, although DAO is a much older technology, its performance benefits and simplicity mean that it is still in very widespread use.

There are other good reasons for continuing to teach DAO in this book, though. DAO and the standalone scenario are much simpler to teach. The client-server scenario, where Access is, in effect, used as a front-end (or user interface) to a back-end database server (like SQL Server), introduces a range of architectural issues and the need to be able to use the back-end database effectively. This kind of material requires a steep learning curve and is a big enough topic for several books in itself!

In the 2000 edition, we stayed with DAO for the bulk of the development examples throughout the book, although we looked at ADO briefly and included an ADO appendix. In this 2002 edition, as a consequence of DAO aging further, we have decided that it is important to give a full introduction to the client-server scenario and ADO but, because DAO is quicker to learn and remains effective, we have retained our use of DAO through the majority of the book. This balanced coverage of the two data access techniques should prepare you effectively for Access development as it is in the real world today, and for any future decay in the use of DAO.