Error "trapping" (1 Viewer)

tmyers

Member
Local time
Today, 08:15
Joined
Sep 8, 2020
Messages
349
As a general/generic question, is there a way to handle errors such as "cant update this field, because an entry is required in this field"?

I asked something specific a week or so ago, but this is just for more generic purposes. I seem to run into this a lot, and when the error happens, it completely locks the form and prevents any further data entry until the form is fully closed and not saved.

Is there a way to have an event or something that when this error occurs to somehow clear it and allow the user to go back and correct the mistake of not entering data into the required field? I have been solving some of this by simply turning the controls visibility to false until the required field has data, but it some cases this wont work.

How do some of you handle such things?
 

theDBguy

I’m here to help
Staff member
Local time
Today, 05:15
Joined
Oct 29, 2018
Messages
13,202
Hi. If you're looking for an event to use, you can try the Form's OnError event.
 

tmyers

Member
Local time
Today, 08:15
Joined
Sep 8, 2020
Messages
349
I have tinkered with that before, but haven't managed to find a way to handle it that doesnt involve closing the form. Maybe I missed something. I will take a 3rd look at it.
 

Isaac

Lifelong Learner
Local time
Today, 05:15
Joined
Mar 14, 2017
Messages
2,734
I'm not sure, but based on the description you provided, it sounds like maybe the Form is trying to update a record at such time that the record doesn't qualify to be updated yet based on required Table column designs, etc. I may be off base there.

But if so, This is why I usually provide an explicit button or control to be clicked to Save a record. Inside that click event, I do all my validation (to make sure everything is right, BEFORE I try to save the record). Near the end of that code, I run Me.Dirty=False, to force a save.

Then, in the form's BeforeUpdate event, I cancel it, UNLESS a certain form-level boolean variable (i.e., blAllowSave) is turned to True--because if it's turned to True, this means my own code is attempting to do the save. If it's not turned to True, that means the user did one of many things that can, quite unexpectedly, cause Access to try to Save the record).

That's one way of handling it?
 

GinaWhipp

AWF VIP
Local time
Today, 08:15
Joined
Jun 21, 2011
Messages
5,723
Hmm, perhaps this will help...

It pushes the User back to the control that needs required information. If you want to cancel the entire entry the code will need adjusting.
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Today, 07:15
Joined
Feb 28, 2001
Messages
18,347
The whole problem with error handling is recognizing that lots of errors can crop up including some that you expect. However, there can be many causes for the error you named. You have gotten several suggestions for this and they are all good. I cannot tell you what to do, but I can tell you how I approached the problem.

Part 1. Every form had an explicit SAVE button that set a flag (see Isaac's post for a similar approach). That SAVE button did the work and if you did something else (like try to navigate or close the form) my BeforeUpdate event code would catch that you were trying to save a "dirty" form in an unauthorized way. It would cancel any save that didn't go through the CLOSE button.

Part 2. Every data-oriented control on every form was either critical or non-critical. In the FormCurrent routine, code would set some flags to FALSE. Every critical control's LostFocus event would examine the value in its control and, if it was a value that COULD be saved, it would set the flag to TRUE.

Part 3. Every bound control called a common routine that would make some tests. For example, there was a master flag that would be set each time via ReadyFlag = Crit1 AND Crit2 AND Crit3 AND.... CRITn that I would use to make the SAVE button visible. Therefore, if all critical values had not been handled yet, you literally had NO controls that would allow you to save the values or close the form. This common routine would test whether the form was "dirty" and if it was, it turned ON the UNDO button and also turned off the form's navigation controls and CLOSE button. Therefore, there would be a time when your only choice was to either UNDO everything or keep on entering data until the SAVE flag would come on. In that state, you could neither close nor save nor navigate. You could only UNDO or continue entering data.

Part 4. The BeforeUpdate event would test whether your record was ready AND whether you used the SAVE button to trigger the record save operation. It worked in concert with...

Part 5. The AfterUpdate event did event logging, adjusted the navigation controls, and diddled with the states of the control buttons.

Yes, this was an extensive bit of work. And it wasn't bullet-proof. But it did a darned good job in taking away a person's opportunity to make a bad mistake by leaving you with bad data.

This is relevant to error handling in this way: Those precautions made a lot of user-induced data errors impossible because I literally did not allow them to see the functions that would give them the chance to screw up. So my approach was to prevent the errors ahead of time.

The other issue is that if you have an error anyway, you have to try to write your code so that after any questionable action, try to check the error flag and if you had an error, you need to drop the users back to a state where they can retry the function just attempted.
 

Users who are viewing this thread

Top Bottom