I think this chapter should mention totals feature available in Datasheet forms, and that the Queries chapter 7 should cross-ref to it.

When I tried to follow your example (without having the field names in place prior to entering the first record of information, autorecord recorded each field of information as a record (very annoying). This didn't happen if the field names were in place prior to entering a record of information.

Says "Every table must have a primary key." Access doesn't require that a table have a primary key, so
"must" is a bit strong. Certainly every Access table should have a primary key by the time a database
designer is done, but the lack of a primary key requirement is helpful at times early in the design
process.

The described procedure (using "drag the mouse to select more than one field") implies that only adjacent
fields can be joined to create a composite primary key. Using the Ctrl key to multi-select fields (and
keeping it pressed while right-clicking), you can also select non-adjacent fields.

The text says that using a more descriptive name than ID for an autonumber primary key is unnecessary. But
that's not true with Access.
There are numerous situations when you are using Access as a front-end to a complex client-server database
with tables linked via ODBC. (Administrator-level types do this, especially with Oracle databases, because
Access provides a civilized interface to the data, especially for composing one-time queries and reports
quickly. Also, for medium sized operations where scalability is less of an issue, it is drmatically faster
to use Access as a RAD environment to build front-ends to high-end Databases than develop Web front-ends;
in this situation, you initially develop the application as an Access database/app - steering clear of
pitfalls such as attachments, value lists for lookup or multiple-value lookup)- and then upsize your
schema, so that the forms, queries, reports and code modules continue to work as your Access tables get
replaced with ODBC-linked tables with the same name.
In this situation, you will not have set up most or all of your telationships in Access, because you would
simply be duplicating what you have already set up in your server database. (It doesn't help much anyway,
since Referential Integrity doesn't kick in for ODBC-linked tables.)
In this case, when you start composing a new join query, Access tries to be helpful and link ID fields in
different tables together, as you note on pg. 205; you have to break these links and set up the links that
matter. If you had named the primary key column CustomerID to begin with, and used the name CustomerID
consistently as a foreign key, Access would actually be helpful instead of forcing you to fight against
it.

This is only a suggestion...

Database experts choose different approaches for this topic. Personally, I use an AutoNumber ID field
occasionally, but I avoid it when I have a solid data-centric candidate key such as an account number, a
login ID, a product number, etc. I appreciate the author's perspective, but I think it would be good to
acknowledge that this sixth principle is less universally accepted than the other principles.

(If you want to take the concept further, principle #3 on page 82 also leads to disagreement of opinion. I
don't happen to mind nulls in database fields, but some database experts do, and they suggest creating
multiple tables with 1:1 relationships, intentionally NOT including all details in one place.)

Says "Any table's first rule is that each record it contains must be unique." It certainly is important to
do so for relational database integrity, and it's always a good idea, but Access doesn't require that a
table have a primary key; Access does allow duplicate records. The wording "rule" implies (to me, anyway)
a rigorously enforced constraint.

I find this behavior very helpful when importing data from less-than-optimal external data sources. I
create Access tables, use Find Duplicates queries to isolate the rogue data, manually fix the issues, then
implement primary keys.

Because the "Filter" and "Order by" boxes in the Property sheet are blank, perhaps delete the following phrase from the figure legend:

"including the sorting (page 94) and filtering settings (page 97) you've applied to the datasheet,"

(or else amend the figure)

[154/5] Both pages;
I have tried to create the relationship exactly as shown, but get the following error message "Relationship must be on the same number of fields with the same data types"

Because the "Filter" and "Order by" boxes in the Property sheet are blank, perhaps delete the following phrase from the figure legend:

"including the sorting (page 94) and filtering settings (page 97) you've applied to the datasheet,"

(or else amend the figure)

Add "and enter, then save" after "change the price of any product." (But maybe that's just my system's requirement, not everyone's.)

Add "and enter, then save" after "change the price of any product." (But maybe that's just my system's requirement, not everyone's.)

An example of an In keyword is given:

In (14,15,18)

This is clearly wrong, as it then states that the filter expression matches records with ID values of 14,15,16. The expression should be:

In (14,15,16)

In the first bullet, it states that one should use a totals query if grouping with one field. It then points to the top of Figure 9-1 as an example. Figure 9-1 in fact shows 2 levels of grouping, not one.

Third paragraph should read, "Report Layout Tools | Format | ..."

also mention:

Create-->Forms-->Multiple Items

{ch 13} ch 13;
I think this chapter should mention totals feature available in Datasheet forms, and that the Queries chapter 7 should cross-ref to it.

also mention:

Create-->Forms-->Multiple Items

??

also mention:

Form Design Tools --> Arrange --> Control Layout --> Tab Order

[chs 15, 19] ch 15 & ch 19;
It would be helpful if these chapters mentioned that exports can also be accomplished with the OutputTo macro.

also mention:

Form Design Tools --> Arrange --> Control Layout --> Tab Order

???

Insert "-->Trust Center Settings" before "Choose the Trusted Locations section."

Insert "-->Trust Center Settings" before "Choose the Trusted Locations section."

Had to click toolbar buttons to get the same display shown in the figure (with the Project and Properties windows).

Had to click toolbar buttons to get the same display shown in the figure (with the Project and Properties windows).

Did not find the Visual Basic for Applications Language Reference.

Did not find the Visual Basic for Applications Language Reference.