Microsoft Access 2013 Step By Step

Errata for Microsoft Access 2013 Step By Step




The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted Date Corrected
PDF
Page xiii
whole page

In your download of Microsoft® Access® 2013 Step By Step Practice Files it is missing Chapters: 11, 12 and 13. Pls. correct!

Note from the Author or Editor:
All practice files are now available at http://examples.oreilly.com/9780735669086-files/ Thanks for letting us know these were missing.

lammetje  Mar 09, 2013  Mar 18, 2013
Printed
Page 93
TIP at bottom

Do NOT use "first three of last name, first two of first name" as a "unique" identifier. Think "Jane Smith" and "James Smithers" -- why teach the novice user bad habits!?!

Note from the Author or Editor:
In the tip at the bottom of page 93, please change the first two sentences to the following (eliminating the word "unique") and add the parenthetical sentence: Tip The CustomerID field contains an identifier for each customer and is the table’s primary key field. In this case, the identifier is not an autogenerated number, but the first three letters of the customer’s last name combined with the first two letters of his or her first name. (Obviously, this method produces unique identifiers only if no two names begin with the same letters.)

Anonymous  Mar 06, 2013 
Printed
Page 96
#9

Let's get this straight ... FIRST you enter first three and first two, then you have to enter first name and last name ... Isn't that redundant? Why not have Access take the first three and first two AFTER entering the first name and last name? ... that is, if you were going to use that as a primary key, which you shouldn't!

Note from the Author or Editor:
On page 96, after the list and before step 11, please add the following tip: Tip By the time you finish this book, you will know how to have Access create the CustomerID entry based on the FirstName and LastName entries, so that you don't have to type it.

Anonymous  Mar 06, 2013 
Printed
Page 163
Table at bottom of page

Recheck the descriptions for SIngle and Double. As stated, Single gives more range than Double?!?

Note from the Author or Editor:
In the table at the bottom of page 163, in the Double row, change the description to "Numeric floating point values from -1.797 x 10 to the 308th to +1.797 x 10 to the 308th" (in other words, change two instances of "38th" to "308th")

Anonymous  Mar 06, 2013 
Printed
Page 164
2nd paragraph

"... you prevent the entry of invalid values ..." Not exactly; you might reduce the risk of entry of values too large or too small, but that does nothing to prevent "invalid" values.

Note from the Author or Editor:
On page 164, change the first sentence of the second paragraph from "By setting the Field Size property to the setting that allows the largest valid entry, you prevent the entry of invalid values." to "By setting the Field Size property to the setting that defines the range of valid entries, you prevent the entry of values that are too large or too small."

Anonymous  Mar 06, 2013 
Printed
Page 173
in box at top

I thought that using a single "@" character would require entry of a single text character ... is it supposed to apply to more than one character?

Note from the Author or Editor:
The custom format works as stated, but the use of the @ symbol might require more explanation. At the end of the Tip in the box on page 172, please add the following: For more information about custom format characters, search on <I>custom formats<\I> in Access Help.

Anonymous  Mar 06, 2013 
Printed
Page 177
The last sentence of the Set Up

"Database view" should be "Datasheet view."

Joyce Cox
Joyce Cox
O'Reilly Author 
Aug 18, 2013 
PDF
Page 181
#20

On the Fields tool tab, in the Field Validation group, click the Validation button. Then click Validation Rule. Notice that the Expression Builder dialog box opens with the FieldTest table selected in the Expression Elements list and its fields displayed in the Expression Categories list. If you click "Validation Rule" by default meaning the "Field Validation Rule" then the FieldTest table doesn't appear in the "Expression Builder" dialog under "Expression Elements" list. You should click on "Record Validation Rule" so the table FieldTest appears in the "Expression Builder" dialog under "Expression Elements" list. Mentionning "Field Validation Rule" or "Record Validation Rule" is missing as the first category "Field" or "Record" is missing in the text.

Note from the Author or Editor:
In Access 2013, the options displayed when you click the Validation button are Field Validation Rule and Validation Rule; in other words, there is no Record Validation Rule option, so the step is correct as is. However, to avoid confusion, please change the second sentence of step 20 on page 181 to the following: "Then click <b>Validation Rule<\b> (not Field Validation Rule)."

Anonymous  Jun 13, 2013 
Printed
Page 185
TIP at top

A potential downside isn't described -- someone will have to remember or discover the value list if there ever IS a need to change something. Also, just because a table is used to store potential choices/values, I don't understand why that means they "will change often".

Note from the Author or Editor:
In the Tip at the top of page 185, please change the second sentence to the following: "If a field has a lot of potential entries, or if the entries might change, you can link them to a table."

Anonymous  Mar 06, 2013 
Printed
Page 187
#15

What if User 1 enters "Utah" and User2 enters "UT", and both users click "Yes" to allow the new entries to be added to the value list? Seems more "user-friendly" to not allow any additions to the list, whether in a table or as a value-list, unless there's further validation...

Note from the Author or Editor:
Please move the following sentence "Let's ensure that users can select values from the list but cannot change it." from its current position before step 18 to before step 17.

Anonymous  Mar 06, 2013 
Printed
Page 191
#10

Only displaying the first name of the employee only works if there are very few employees and none share the same first name. The agency I work at has under 200 employees, but there are over 60 that share names. Instead, what about using a query to generate a [FirstName] & " " & [LastName] field and displaying that?

Note from the Author or Editor:
On page 191, after step 11, add the following tip: Tip Obviously, this method of identifying the salesperson works only if each person has a different first name, as is the case with the sample database.

Anonymous  Mar 06, 2013 
Printed
Page 199
First paragraph

"... Access must understand the relationships ..." The implication of the first and second paragraphs is that Access can only do queries if you've (pre-)defined relationships. You can use a query to DEFINE the relationship (for the query).

Note from the Author or Editor:
Please replace the paragraph at the top of page 199 with the following: "Before a query wizard can create a query that uses multiple tables, relationships must exist between the fields in those tables."

Anonymous  Mar 07, 2013 
Printed
Page 204
First full paragraph

In previous versions of Access, it was possible to (temporarily) show a relationship between tables in design view by dragging a shared field(s) between tables. In fact, unless this was done, a "Cartesian Product" resulted. Does Access 2013 require all tables to have relationships BEFORE a query can be manually created? (similar to the TIP in step 6 on page 200?)

Note from the Author or Editor:
Please add the following Tip after the second bullet at the bottom of page 203, running subsequent bullets to the top of page 204 as necessary. "TIP If you add tables to the Query Designer for which you have not already defined relationships, Access attempts to relate the tables based on common field names. You can also create relationships by dragging a field from one table to another in the Query Designer. These relationships exist only for the query and are not reflected on the database's Relationships page."

Anonymous  Mar 07, 2013 
Printed
Page 222
3rd paragraph from bottom (starts w/ "If the table...

The last sentence refers to deleting discontinued products. Why? Won't deleting an item from the [Products] table leave an orphan record in the [OrderDetail] table?!? Why delete the products at all? DASD's cheap.

Note from the Author or Editor:
Delete queries are indeed dangerous, as I hope the text and exercise make clear. Just in case, please add the following sentence to the "In this exercise" paragraph at the top of page 223. "You'll also see why you have to be extremely cautious when using delete queries and why you might want to avoid them when working with related tables."

Anonymous  Mar 07, 2013 
Printed
Page 227
2nd paragraph

"Ease of data entry is the major consideration when designing a {DATA ENTRY} form..."

Note from the Author or Editor:
On page 227, please change the first sentence of the second paragraph from "Ease of data entry is the major consideration when designing a form, because the easier this process is, the less likely people are to make mistakes." to "When you design a form that will be used to enter data, the major consideration is ease of data entry, because the easier this process is, the less likely people are to make mistakes."

Anonymous  Mar 07, 2013 
Printed
Page 234
#12

If [CategoryID] is, as its name suggests, the primary key of the [Category] table, would there ever be a situation in which it would be desirable for the user "to be able to change the value"?

Note from the Author or Editor:
On page 234, in the paragraph following step 12, please change the first sentence from "Next, suppose we don’t want users to be able to change the value in the CategoryID text box control" to "We don’t want users to be able to change the value in the CategoryID text box control."

Anonymous  Mar 07, 2013 
Printed
Page 234
#15

Because the word "Category" shows up in many places, consider clarifying as follows: "Click the Category Name label control, double-click the word "Category", then delete it and the following space."

Note from the Author or Editor:
Please change step 15 on page 234 as follows, retaining the bold for Category Name and Category: 15 Click the Category Name label control, double-click the word Category, and then delete the selected word and the following space.

Anonymous  Mar 07, 2013 
Printed
Page 237
list at bottom

In earlier versions of Access (pre-2013), a textbox control could also be unbound. It (textbox) doesn't appear on the list of Unbound controls...

Note from the Author or Editor:
Please add a second-level bullet for "Text box" to the top of the Unbound bullet list on page 237.

Anonymous  Mar 07, 2013 
Printed
Page 281
Last section

The section describes making a copy of table(s) in another database. It could be a 'teaching moment' to use this section to point out that having the same data in more than one table, and/or in more than one database leads to issues of data integrity. Which copy is correct? Discuss analyzing the situation to determine if you are migrating ALL data into a (single) new db, or if there are business reasons to have some data in one database (e.g., used by Dept. X) and other data in another (used by Dept. Y), but some 'sharing'. In that case, leave the data where it is and LINK to the other table(s).

Note from the Author or Editor:
On page 281, at the end of the first paragraph of the "importing from other Access databases" section, please add the following sentence: After importing the information, remember to delete it from the source database so that it exists in only one place.

Anonymous  Mar 07, 2013 
Printed
Page 306
TIP @ center

?! " ...open both databases, copy the table ..." What about importing the object from one to another? Also, at least in previous versions of Access/Excel, copying too many rows from Access and attempting to paste them into Excel resulted in loss of rows. Instead, Export from Access to Excel to get ALL rows copied.

Note from the Author or Editor:
Insert the following tip between the first and second paragraphs on page 306: Tip Always proof the results of a copy and paste operation carefully. In the past, some people experienced loss of data when copying many rows of Access data to Excel. When a lot of data is involved, you might want to export the data instead.

Anonymous  Mar 07, 2013 
Printed
Page 342
2nd TIP

In earlier version of Access, the Access support community STRONGLY recommended making a backup copy of the file before running C&R, as it ocassionally failed, corrupting the db. If you elect to have Access automatically run C&R, where's the backup?!

Note from the Author or Editor:
Please change the 2nd tip on page 342 to the following: Tip It’s a good idea to compact and repair a database often. You can even have Access run this utility automatically each time the database is closed, by displaying the Current Database page of the Access Options dialog box, selecting the Compact On Close check box in the Application Options area, and then clicking OK. However, to avoid any chance of corruption, always be sure to back up the database before compacting and repairing it.

Anonymous  Mar 07, 2013 
Printed
Page 361
#17

"In the right pane..." (it's the left pane...)

Note from the Author or Editor:
In Chapter 13, on page 361, at the beginning of step 17, please change "In the right pane" to "In the left pane."

Anonymous  Mar 07, 2013