A comparison of menu options in the Datasheet view of a table, a form, and a query, as illustrated in the following example, will demonstrate the similarity of data entry in all three. The NiftyLionsChap6.mdb database has a table of customer records, as well as a form and a query that contain all the records from the underlying customers table. To follow along with the example, download NiftyLionsChap6.mdb to your hard drive and open the file.
You used the Nifty Lions database previously, in Chapter 5, "Building Tables." Nifty Lions is a mail-order firm that sells all kinds of items, including figurines, T-shirts, and postage stamps, that have lions on them to retail customers in the United States. The structure of the database is similar to the Northwind sample database, but I've streamlined it by keeping all the business within the United States, using fewer suppliers, and recording fewer orders, for example.
Your screen should look like Figure 6.2 (don't worry if the objects are in a different order). If you click in each object and open each menu (File, Edit, View, and so on), you'll find that the selections are quite similar (assuming that you've chosen Always Show Full Menus on the Options tab of the Customize dialog box, available from the Tools menu). Indeed, except for a few extra items on the Insert menus of the table and (to a lesser extent) query, all the commands are the same. You can hide and show columns, create filters, use Access tools, and so on.
Figure 6.2. Form, query, and table datasheets for Nifty Lions Customers data.
If you switch from Datasheet view to Form view in the form, the commands stay the same, except for those related to formatting a datasheet. Because the same form in Datasheet view and Form view looks so different, it's easy to think of them as separate objects. They're not. Except for a few commands and properties that specifically affect the selected view, they are the same object, with the same properties. A form in Form view offers better visibility and sometimes enhanced flexibility, but you are still looking at and editing the same group of underlying records.
To restate the key point, you can enter records in any of the three objects, and the tools and procedures remain nearly the same. Any record that you enter and any editing change that you make are stored in the table and, thus, are reflected in all three objects.
There are some wrinkles to entering and editing records in queries that contain fields from two or more tables. These issues will be easier to understand after you've spent more time with multitable queries. I've therefore postponed a discussion of entering and editing records in queries to Chapter 8, "Queries."