Part III: More-Advanced Access Techniques
776
FIGURE 21.8The Access error message for Error 3197
By default, Access gives the user (Mike, in this case) three choices:l Save the record with the changes he has made.l (^) Copy the changes to the Clipboard.
l Abort the changes altogether.
The first and third options make sense, but the second option (Copy to Clipboard) has never
seemed practical to me. Anyway, there are too many choices for the average user to make, espe-
cially when the options aren’t self-explanatory.
The best option is to offer the user the option of saving his changes or terminating the edit, and
then deliver the message in a format that’s easy to understand. Besides providing a meaningful
error message, you might want to offer to show your users the changes that have been made by
refreshing the current form or opening a form based on the record that has been changed.
The actual error handling is straightforward. A record update throws an error the first time it’s exe-
cuted and your code traps the error. Then all you have to do is give the user the options you think
best. If the user chooses to save the record, the update overwrites the other user’s changes (unless
another locking conflict occurs).
Listing 21.6 shows an example of this type of procedure. Like the previous examples, an edit is
attempted, but if the edit fails, control is transferred to the error handler. However, in the previous
examples the edit either failed or didn’t fail after ten retries. SaveChanges() just gives the user a
chance to overwrite or cancel. (Keep in mind that the message box asking the user whether to can-
cel or save is displayed by the ErrorRoutine() procedure.)
LISTING 21.6
Handling “Data Has Changed” Errors
Public Sub SaveChanges(ID As Long)
Dim db As DAO.Database
Dim rs As DAO.Recordset