Form error event vs. Sub error event

  • Thread starter Thread starter Fred Boer
  • Start date Start date
F

Fred Boer

Hello! Hope everyone is having a great summer!

Recently I made some changes in my Access application, and used code from a
demonstration database. This code makes use of the form's error event. Now,
I always put error handling in all of my procedures, and have never used the
form's own error event. I wonder if I am doing something wrong. (Highly
likely! <g>)

I wonder if someone could outline for me the differences between the two
error handling events? Are there some types of errors for which you need to
use the form's error event rather than a procedure's errorhandling code? If
you put error handling in all your procedures do you need to worry about the
form error event? Is there a particular order in which errors are managed,
for example, the procedure's error handling, and then the form's error
event?

Thanks!
Fred Boer
 
Hi Fred

Error handling in a procedure handles an error that happens because that
code is running. There are other errors that happen at the engine level and
are not related to your code. The Form_Error event lets you handle those
errors.

Examples:
1. A text box is bound to a Number field, and you enter, "dog". When you
press Tab, Access won't let you move out of the field. The error message
says
The value you entered is not appropriate for the field
If you use the Form_Error event, the message is DataErr 2113

2. A control is bound to a field that has its Required property set to Yes.
You type something, press backspace, and try to get out of the field without
supplying an entry. Form_Error fires with DataErr 3314.

3. A control is bound to a foreign key field, where referential integrity is
applied. User enters something that does not match a value in the lookup
table. Form_Error fires with DataErr 3201.

4. A field is "Indexed (No Duplicates)", and the user tries to enter a dupe.
Form_Error fires with DataErr 3022.

5. User tries to close the form while the record can't be saved for some
reason. Access pops up the message asking if they want to close the form
(and lose their edits) or stay with it. IMHO, it's best to leave this
message in place, as I believe the user deserves to have the choice, but you
can trap this in Form_Error if you so desire.

6. Database is split, with backend on the network, and the network fails.
DataErr 3024.

As you can see, Form_Error traps any engine-level error.

The simplest approach is to write a generic routine with a Select Case
statement to handle any error messages that you want to replace with your
own. Set Response to acDataErrContinue after your custom message, or
acDataErrDisplay for the built-in message.

If you set up a default form your yourself as described at:
http://allenbrowne.com/ser-43.html
any new form you make will have the setting to call the generic handler.
 
Dear Allen:

Thanks very much; now it is clear to me. What isn't so clear to me is *why*
I haven't ever implemented error handling such as you describe! A cursory
glance at my application shows that sometimes I used BeforeUpdate code and
sometimes validation rules for controls...but even a cursory look shows me I
have some *big* holes to fill! Ouch! Oh well, it'll be fun to fill them in!

Cheers!
Fred
 
Back
Top