Access Cookbook

Errata for Access Cookbook

Submit your own errata for this product.


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
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