Summary of corrections to "Running Microsoft Access" and the
PROMPT.MDB database as of 3/25/93.

Chapter 12, Page 270, line 2
should read: "... or choose the Select Form command from the 
Edit menu)"


Chapter 14, Page 312, "Adding Calculated Values"
To properly display totals when some months have no sales for
a particular item, the formula should read:
 =IIf(IsNull([Jan]),0,[Jan]) +IIf(IsNull([Feb]),0,[Feb])
     +IIf(IsNull([Mar]),0,[Mar])


Chapter 19, Page 402
Using "Is Not Null" is not a good example of a single field validation
rule.  Microsoft Access Version 1.0 checks validation rules only via
form controls.  However, Access performs validation rule checks ONLY
if data in the control changes.  If a user skips over a control bound
to a field that must contain data (Not Null), leaving that control
unchanged, Access will not enforce the validation rule.  You should
check for Null in BeforeUpdate for the form.  A better example would be
to create a rule that "Days to Build" must always be greater than zero
(>0) and include a default value of 1 for the "Days to Build" field.


Chapter 19, Pages 406-407
The section on "Assisting Data Entry" should also include an explanation
for the second macro action in the sample.  The SendKeys {F2} causes the
cursor to position at the end of the data value that was just copied 
into the [Long Description] control.  This is handy to position the
entry point ready to type additional information.


Chapter 19, Page 409, Figure 19-12
The setting for the Item argument in the second SetValue should
read:  Forms![Catalog - Chap 14]![Price]


Chapter 19, Page 411, Figure 19-15
The setting for the SQL Statement argument in the RunSQL action
should read:
  DELETE DISTINCTROW [Item Components].[Catalog Item ID]
   FROM [Item Components] WHERE [Item Components].[Catalog Item ID] =
   Forms![Catalog - Chap 14]![Catalog Item ID];


Chapter 19, Page 411, paragraph immediately under Figure 19-15
should begin:
  "Notice that the Condition argument in the first Action of the
Delete Items macro uses ..."


Chapter 19, Pages 424-426, "Orders Form Properties" and
"Picking a Customer on the Orders Form"
Although setting Allow Updating to Any Tables does let you update
customer information on the "one" side of the query as documented,
it also has the unwanted side effect of attempting to delete the
customer row when you try to delete an order.  This works OK when
you are deleting the last order for a customer (but the customer
row disappears!), but generates an error if the customer still has
orders outstanding.  The sample database has been changed to set
Allow Updating to Default Tables.  The desired update to customer
information is accomplished with unbound controls and additional
macro routines in the Orders macro.


Chapter 19, Page 430, Figure 19-39
The setting for the Macro Name argument in the RunMacro action
should read:
  Orders - Chap 19.Calc Tax



Improvements to PROMPT.MDB:

OnDelete macros have been added to all forms in the application to
trap all possible referential integrity violations and display a
more informative message box or take appropriate cascading delete
action.

Macros have been added to BeforeUpdate and AfterUpdate of the 
Display / Add Components form to cause any change in Our Cost to 
also be reflected in any related rows in the Catalog Items table.

Updates to Customer address information from the Orders form are now
accomplished via unbound controls and macros.  See above.

An OnDelete macro has been added to the Orders Details Subform and the
Catalog Subform to correctly re-calculate values on the main form
whenever you delete a row in the subform.  Deleting a row does not
trigger the subform AfterUpdate routine that handles this calculation
when you change or add a record.