An Access application is just the same as any other kind of application, but one built using Access tools. It is a collection of interrelated objects working together to achieve a specific objective, usually business-orientated.
That didn't tell us that much, did it? Maybe we should have asked a different question:
The main difference is that Access is designed from the ground up to handle data, quickly, efficiently , and lots of it. Access applications therefore tend to be data intensive . Using Access to create such applications can be easier and faster and can produce better results than using anything else. Obviously today's applications also need to be able to present a modern and efficient graphical user interface and to allow for all sorts of additional functionality, like connections to other applications or to the Internet - Access provides for this as well, but this is not its primary goal. It is, for example, entirely possible to create an Access application that simulates shooting missiles at alien spacecraft as they move across a Martian landscape but this would certainly not be the best way to do it!
When you create a new database file ( .mdb file) in Microsoft Access 2002, the first thing that you see is the database window. This is a container that will eventually hold a wide variety of different objects. Tables will be used to store data; queries will be designed to retrieve data in meaningful ways; forms, reports , and data access pages will all be used to display the results of those queries in ways that users can understand; and macros and VBA modules will provide the program logic which 'glues' the whole application together.
If you use Access 2002 to create a project ( .adp file) instead, then the database window will also show additional server-side objects (such as database diagrams and stored procedures), which may also be included to make up the application.
All of these objects can play an important role in providing the functionality of the end product - whether it is hosted solely in an Access database or uses a client-server database project.
The aim of this book is to illustrate the important role played by VBA in orchestrating these objects, in binding them together through the use of logic to control workflow and to implement specific business rules, and in turning a collection of individual objects into a coherent and effective application. Yes, we want to teach you how to use VBA, but to do that without first telling you how to design an application would be irresponsible.