Before_Update and GotoRecord

[Guest]

I am a bit befuddled by the use of the Before_Update event. Occasionally I
run into problems and I dont always know why. I eventually try multiple
things and find my way, but I am still not very clear on the donts.

Is it generally a bad idea to force the Before_Update event by a call to one
of the GoToRecord methods? Let say a form has custom navigation buttons and
AddNew button. On the click event of these buttons, is it better to do your
entries-validation and based on some return value, determine whether to call
the appropriate goto... method? Conversely, is it a bad idea to place your
validation codes in the B4_Update procedure? - in which case (at least in my
programming) whenever you navigate away from a Dirty record and validation
fails, you get that nasty Access error 'Cant save record ...'. Or, how about
using on error resume statements to turn that error off?

Please advise. I'm sure that is on the top 10 list of access frustrations.

 

[Guest]

Validating data at the control level should be done in the Before Update
event; however, you can't change the data there. All you can really do is
present a message to the user and cancel the update event.

The form's before update event can be used to validate data at the record
level or allow the user to cancel the update already made in the fields.

 

[David W. Fenton]

Validating data at the control level should be done in the Before
Update event; however, you can't change the data there. All you
can really do is present a message to the user and cancel the
update event.

It's important to emphasize this point: use controls that limit the
data entered to the valid values only, like option groups, combo
boxes, listboxes, checkboxes and so forth. If you need to have a
textbox that the user can type anything into but the values need to
be checked, do that in the BeforeUpdate event of the control itself.

The result will be that by the time you get to the form's
BeforeUpdate event, all the data will already be valid, and you'll
only need to validate one type of issue:

The form's before update event can be used to validate data at the
record level or allow the user to cancel the update already made
in the fields.

This is where you'd validate combinations of values in fields that
are interdependent in some fashion, since all the individual values
have already been validated as correct.

The key point is:

Don't let the user complete entering anything invalid into any
field, and then you have less to validate at the record level.

 

[Guest]

That is the way I usually do it. There is one case where the form After
Update is necessary. That is for cross validation. That means if the value
of one control can constrain the values in another, the form event is better
because in a Windows environment, the user can enter data in any order, so
you don't know what the validation rules are until both controls are
populated.

 

[David W. Fenton]

There is one case where the form After
Update is necessary. That is for cross validation. That means if
the value of one control can constrain the values in another, the
form event is better because in a Windows environment, the user
can enter data in any order, so you don't know what the validation
rules are until both controls are populated.

But you could also write a subroutine that does it and checks all
the relevant fields and doesn't prompt the user until the last of
them has been updated. I do this all the time for enabling command
buttons that shouldn't be clicked until all the fields are filled
out. That's very simple validation, but what you need would just be
a slightly more complex variation of the same thing.

Again, I'd do the validation as soon as possible, as close to the
actual editing of a particular field as I could get.

 

[Guest]

The only issue I have with your approach is more code running which makes the
form slower.

I typically don't have any buttons on my form that can't be used prior to
the current record being updated.

 

[David W. Fenton]

The only issue I have with your approach is more code running
which makes the
form slower.

In what world does a couple of milliseconds make a different? Not in
the REAL WORLD.

I typically don't have any buttons on my form that can't be used
prior to the current record being updated.

I wasn't suggesting there be any buttons of that kind. I was
suggesting you use the BeforeUpdate events of the controls on the
form to validate the data in each field as it is entered.

The idea that this amount of code running will slow down the form is
simply preposterous. The only thing that slows down an Access form
is the retrieval and processing of large amounts of data, and you
didn't describe any kinds of validation that would require the
retrieval/processing of large data sets.

 

[Guest]

Thanks for the many insights. However, I have situations in which validation
is based on the entries of multiple fields, and is therefore better suited to
record-level approach. The form's Before_Update event was provided for this
very reason and more. It is workable. I need guidelines on how to use it
correctly. Is it good programming to set an error trap prior to any action
that will save the record. That way, Access' message gets suppressed and the
editted record stay in view.

Also, can a bound control's value be changed during the Before_Update event,
without causing an error?

 

[Guest]

Code does not run in 0 time. Any processing whether or not any data
retrieval takes place consumes some time. Granted, it may in milliseconds,
but IMHO, efficiency is an important design consideration.

I think you got a little over excited. I was not attacking your opinion,
only offering a different perspective. If I strongly disagreed with your
method, you would know it. In your last paragrahp, neither statement is true.

 

[David W. Fenton]

Code does not run in 0 time. Any processing whether or not any
data retrieval takes place consumes some time. Granted, it may in
milliseconds, but IMHO, efficiency is an important design
consideration.

A couple of milliseconds is as close to zero as is possible, since a
human being can't perceive the time difference. You seem to
subscribe to the theory that caused Microsoft to implement the
"light" forms, with no code modules, but testing proved that they
weren't any faster in the real world than forms with modules, even
modules that actually ran some code.

I think you got a little over excited.

You made a categorical statement that, while perhaps technically
true, was really quite misleading for real-world situations.

I was not attacking your opinion,
only offering a different perspective. If I strongly disagreed
with your method, you would know it. In your last paragrahp,
neither statement is true.

No, both statements are true *for the real world*, for pragmatic
evaluation of UI performance.