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.
| Version |
Location |
Description |
Submitted By |
Date submitted |
Date corrected |
| Printed |
Page 57
Code example |
when I run the code I get the error,
"Invalid bracketing of name '[forms!frmAlbumsPrm!cboMusicType]'.
The debugger points to the line of code:
qdf("Forms!frmAlbumsPrm!cboMusicType") = _
Forms!frmAlbumsPrm!cboMusicType
AUTHOR: For reasons I don't understand, the query was set up with invalid
parameters on the Query|Parameters menu. Although you can fix those up
and get the demo to work (I simply set up the brackets in that dialog
box to be correct, matching the
[Forms]![FormName]![ControlName]
Syntax, it may be easier to simply delete the parameters in the
Query|Parameters dialog box while editing the qryAlbumsPrm query. Either
way, the demo works fine.
{example database 08-05.MDB}
The comments in Sub1 say -
Public Sub TestSub1()
Dim intCounter As Integer
' This version of the Sub
' uses many comment lines.
' Comment lines are stored with the
' code and loaded into memory
' when Access compiles the module.
'
'
'
' This uses memory and increases
' the work the the Access Basic
' parser has to do. Since Access
' Basic is an interpreted
' language, it has to parse
' every line, whether its a
' comment or not.
'
' This Sub will run slower than
' its equivalent which uses no comments.
'
The comments are incorrect - VBA is NOT interpreted, and comments
shouldn't affect speed
|
Anonymous |
|
|
| Printed |
Page 80
Step 7 |
Step 7 should be the code for the cmdNext's Click event, but the code shown is
actually that for the cmdLast's Click event, which is repeated again in Step 8.
Step 7 NOW READS:
Private Sub cmdNext_Click()
acbMoveNext Me
End Sub
|
Anonymous |
|
Sep 01, 2003 |
| Printed |
Page 87
Form_Resize procedure previously looked like this |
ExitHere:
Exit Sub
HandleErr:
fInHere = False
Resume ExitHere
End Sub
NOW READS:
ExitHere:
fInHere = False
Exit Sub
HandleErr:
Resume ExitHere
End Sub
Note the new position of the fInHere reset line of code.
|
Anonymous |
|
Sep 01, 2003 |
| Printed |
Page 149
Section 3.13, second paragraph in the Solution statement |
The book makes a reference to "08-13.MDB" but that file doesn't exist on the CD.
Reference NOW READS "03-13.MDB"
|
Anonymous |
|
Sep 01, 2003 |
| Printed |
Page 282
IN PRINT: 3rd line from the bottom |
ReDim Preserve mavarObjects(1 To intItem, 1 To ahtcMaxCols)
READER: This line of code fails when the initial object count is not equal to
the item count. This is because (using the Preserve option) you can only resize
the last array dimension, not the first.
AUTHOR:Yep, that's true. Just never noticed it because On Error Resume Next is
set on. It doesn't seem to affect the behavior of the application--that
is, the correct things get backed up, as far as I can tell.
So, to fix it, I modified the form to work better -- that is, it uses a
Collection containing Info class instances, where the Info class keeps
track of File information.
NOTE: the corrected example for section 6.8, "Back Up Selected Objects to Another
Database", is names "06-08New.zip".
(Chapter 10, Example 10-05) Downloadable Example Code for Access 97
Access97 does not recognise the "DAO." (but I believe that Access2000
does) - the code for Access97 should be
Dim db As Database
Dim wrk As Workspace
Dim rstUsers As Recordset
Dim rstGroups As Recordset
Dim rstUserGroups As Recordset
|
Anonymous |
|
|
| Printed |
Page 423
Step 7 comment on "DblClick Event" |
Step 7 (continued on page 423) of calendar popup says the event is under the Other
tab of the control's property . . . but I cannot find DblClick option there.
AUTHOR: This is one of those things that has changed since we originally wrote
the book, and we missed it. I cannot find any way to "hook" the DblClick
event from the designer, yet it continues to work!
The only way to add this code that I can find is to follow these steps
(and I may be missing something):
1.) With the form open in Design view, select the View|Code menu item to
show the code editor.
2.) From the Object drop-down list in the upper-left corner of the code
window, select the control name (ocxCal)
3.) From the Procedure drop-down list in the upper-right corner of the
code window, select the event name (DblClick).
This inserts the event handler stub, and then you can modify it so that
it looks like the code in the book.
|
Anonymous |
|
|
| Printed |
Page 432
Properly Secure Your Database recepie |
READER COMMENTS:
Carefully following "Properly Secure Your Database", page 432 does not
work. Setting up users and accounts after closing the wizard, as
directed, I was never able to log back in as those users using my Admin
password or no password or any other password thus could not change the
user passwords and set permissions as directed on p 439.
AUTHOR RESPONSE:
Okay, I tried the steps myself and discovered that the latest
incarnation of the security wizard is more secure then it used to be.
The problem is that we fail to discuss the Database Open permission in
the 10.1 topic. Normally, everyone in the Users group gets this
permission but after running the Security Wizard this permission is
revoked from all accounts other the Admins members.
You could have explicitly allowed this permission in Step 4 (on page
436) of the wizard (Would you like to grant the Users group some
permissions?). But then all new users would have this permission and
this would create a security hole of sorts.
(By the way, Step 5 on this same page should say that the new account
that is created will take the same name as your Windows login account.
The account name will be Administrator only if you are logged into
Windows under that name.)
A better idea would be to add this permission for all the new groups you
created in Step 4 (on page 440). However, in reality, steps 3 and 4 need
to be reversed since you need to assign the database open permission to
the groups before you can open the database using the new user accounts.
The other thing to note is that Step 4 should emphasize that it needs to
be done using the new Administrator account.
To add the new Database Open permission using the User and Group
Permissions dialog, you need to select Database as the Object Type and
check the Open/Run permission. Do this for all the new groups you
created. Then log back in using the new user accounts with no password
and all should be well.
|
Anonymous |
|
|
| Printed |
Page 460
Code example 10.5, look over groups to which user belongs |
There is an error in this code excerpt, from the function acbListUsers(), in section 10-5:
' Now loop through all the groups to which that user
' belongs, hooking up the rows in tblUserGroups.
For intJ = 0 To usr.Groups.Count - 1
rstGroups.Index = "Group"
rstGroups.Seek "=", usr.Groups(intJ).Name
With rstUserGroups
If Not .NoMatch Then
.AddNew
!UserID = rstUsers!UserID
!GroupID = rstGroups!GroupID
.Update
End If
End With
Next intJ
The line
If Not .NoMatch Then
should read
If Not rstGroups.NoMatch Then
because the search was done on rstGroups not on rstUserGroups.
|
Anonymous |
|
|
| Printed |
Page 509
Discussion Code |
The reference to the constant HINSTANCE_ERR should be acbcHInstanceErr. The code
crashes at HINSTANCE_ERR (unable to find variable).
AUTHOR: There's nothing wrong with the sample
code, although there's "air code" in the book that didn't get updated to
match the code in the demo.
The code in the book needs to be updated to use acbcHInstanceErr, and
that constant needs to be made public where it's defined in the sample
code.
|
Anonymous |
|
|