I found that I had to calls to my validation code in a number of places,
before a close, before a .movenext, etc. I couldn't put it in
..before_update or .before_insert because a failed validation would interrput
those actions and cause an error. I keep bumping into advice to use "the
access way," (not necessarily about this particular issue), but not always
an explanation of what it is. Is there "an access way" to validate a form
before saving? Or is "the access way" to put validation on each control?

TIA
LAS

"LAS" <(E-Mail Removed)> wrote in
news:i4gtv0$148$(E-Mail Removed):

> I found that I had to calls to my validation code in a number of
> places, before a close, before a .movenext, etc. I couldn't put
> it in .before_update or .before_insert because a failed validation
> would interrput those actions and cause an error. I keep bumping
> into advice to use "the access way," (not necessarily about this
> particular issue), but not always an explanation of what it is.
> Is there "an access way" to validate a form before saving? Or is
> "the access way" to put validation on each control?

1. For single controls:

a. choose the most specific control type and limit user input to
valid values.

b. validate in the control's BeforeUpdate event.

2. For groups of fields whose values are interdependent:

a. write a validation routine for the set of controls and call
that single validation routine in the BeforeUpdate of all the
controls.

OR

b. create a user interface that steps the user through choosing
values one at a time, with each validated individually at each
step. The standard MS wizard interface is very good for this
because it's quite familiar to users.

In other words, do your validation as close to the editing of each
individual piece of data as possible.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"LAS" <(E-Mail Removed)> wrote in
news:i4gtv0$148$(E-Mail Removed):

> I found that I had to calls to my validation code in a number of
> places, before a close, before a .movenext, etc. I couldn't put
> it in .before_update or .before_insert because a failed validation
> would interrput those actions and cause an error. I keep bumping
> into advice to use "the access way," (not necessarily about this
> particular issue), but not always an explanation of what it is.
> Is there "an access way" to validate a form before saving? Or is
> "the access way" to put validation on each control?
>
> TIA
> LAS
>
>

The before_update is where you usually want validation to occur, either
the control's version of the event if you are only validating the
control, or the form's version if validating consistency between
controls.

They are supposed to interrupt those actions because logic says you do
not want to write erroneous data to the tables.

If you get an error, you have incorrectly coded the validation or are
not correctly handling the cancellation of the update,

But if my application works best to do some validation after all the data
has been entered by the user (and there are some reasons for that sometime),
how does one validate? I understand how to validate control by control,
but my question is specifically how to deal with the failure if validation
was in the before_update event of the form.

"David W. Fenton" <(E-Mail Removed)> wrote in message
news:Xns9DD88CB0F5211f99a49ed1d0c49c5bbb2@74.209.136.97...
> "LAS" <(E-Mail Removed)> wrote in
> news:i4gtv0$148$(E-Mail Removed):
>
>> I found that I had to calls to my validation code in a number of
>> places, before a close, before a .movenext, etc. I couldn't put
>> it in .before_update or .before_insert because a failed validation
>> would interrput those actions and cause an error. I keep bumping
>> into advice to use "the access way," (not necessarily about this
>> particular issue), but not always an explanation of what it is.
>> Is there "an access way" to validate a form before saving? Or is
>> "the access way" to put validation on each control?
>
> 1. For single controls:
>
> a. choose the most specific control type and limit user input to
> valid values.
>
> b. validate in the control's BeforeUpdate event.
>
> 2. For groups of fields whose values are interdependent:
>
> a. write a validation routine for the set of controls and call
> that single validation routine in the BeforeUpdate of all the
> controls.
>
> OR
>
> b. create a user interface that steps the user through choosing
> values one at a time, with each validated individually at each
> step. The standard MS wizard interface is very good for this
> because it's quite familiar to users.
>
> In other words, do your validation as close to the editing of each
> individual piece of data as possible.
>
> --
> David W. Fenton http://www.dfenton.com/
> contact via website only http://www.dfenton.com/DFA/

The problem is that if I have "If fncValidated() = false then
exit sub
end if
in the Before_Update event of the form, and the update was triggered by a
..movenext, then the movenext can't complete and I get an error. I'd have to
go and re-create the problem (I took the validation out of before_update and
put it before .movenext, .addnew, etc.), to remember the exact error.

"Bob Quintal" <(E-Mail Removed)> wrote in message
news:Xns9DD8961ABD5FCBQuintal@69.16.185.250...
> "LAS" <(E-Mail Removed)> wrote in
> news:i4gtv0$148$(E-Mail Removed):
>
>> I found that I had to calls to my validation code in a number of
>> places, before a close, before a .movenext, etc. I couldn't put
>> it in .before_update or .before_insert because a failed validation
>> would interrput those actions and cause an error. I keep bumping
>> into advice to use "the access way," (not necessarily about this
>> particular issue), but not always an explanation of what it is.
>> Is there "an access way" to validate a form before saving? Or is
>> "the access way" to put validation on each control?
>>
>> TIA
>> LAS
>>
>>
>
> The before_update is where you usually want validation to occur, either
> the control's version of the event if you are only validating the
> control, or the form's version if validating consistency between
> controls.
>
> They are supposed to interrupt those actions because logic says you do
> not want to write erroneous data to the tables.
>
> If you get an error, you have incorrectly coded the validation or are
> not correctly handling the cancellation of the update,
>

LAS wrote:

> But if my application works best to do some validation after all the data
> has been entered by the user (and there are some reasons for that
> sometime),
> how does one validate? I understand how to validate control by control,
> but my question is specifically how to deal with the failure if validation
> was in the before_update event of the form.

In the BeforeUpdate event you run your test code. When there are problems
you display a message to the user and cancel the update. It does not matter
what action triggered the update. It will not even be attempted if you
cancel the update event.

"LAS" <(E-Mail Removed)> wrote in
news:i4mh36$135$(E-Mail Removed):

> The problem is that if I have "If fncValidated() = false then
> exit sub
> end if
> in the Before_Update event of the form, and the update was
> triggered by a .movenext, then the movenext can't complete and I
> get an error. I'd have to go and re-create the problem (I took
> the validation out of before_update and put it before .movenext,
> .addnew, etc.), to remember the exact error.
>

If fncValidated() = false then
cancel = true
exit sub
end if

would have saved you headaches.

Please do yourself a favor and read a book, or take a course....




> "Bob Quintal" <(E-Mail Removed)> wrote in message
> news:Xns9DD8961ABD5FCBQuintal@69.16.185.250...
>> "LAS" <(E-Mail Removed)> wrote in
>> news:i4gtv0$148$(E-Mail Removed):
>>
>>> I found that I had to calls to my validation code in a number of
>>> places, before a close, before a .movenext, etc. I couldn't put
>>> it in .before_update or .before_insert because a failed
>>> validation would interrput those actions and cause an error. I
>>> keep bumping into advice to use "the access way," (not
>>> necessarily about this particular issue), but not always an
>>> explanation of what it is. Is there "an access way" to validate
>>> a form before saving? Or is "the access way" to put validation
>>> on each control?
>>>
>>> TIA
>>> LAS
>>>
>>>
>>
>> The before_update is where you usually want validation to occur,
>> either the control's version of the event if you are only
>> validating the control, or the form's version if validating
>> consistency between controls.
>>
>> They are supposed to interrupt those actions because logic says
>> you do not want to write erroneous data to the tables.
>>
>> If you get an error, you have incorrectly coded the validation or
>> are not correctly handling the cancellation of the update,
>>
>
>
>

"LAS" <(E-Mail Removed)> wrote in
news:i4mguc$da$(E-Mail Removed):

> But if my application works best to do some validation after all
> the data has been entered by the user (and there are some reasons
> for that sometime), how does one validate? I understand how to
> validate control by control, but my question is specifically how
> to deal with the failure if validation was in the before_update
> event of the form.

I would say that, as a general principle, validation is not often
best implemented at the record-level event.

One of the issues on which many disagree with me, however, is on the
question of using a single form for both adding and editing records.
I very often have a separate unbound form for adding new records,
and allow the creation of the new record only when the controls on
the unbound New Record form have been properly filled out. I don't
include all fields on the New Record form, only the ones that are
required to create a valid record.

This avoids a number of issues in the full detail form in that you
then need only validate in the events related to editing, and don't
have to worry about the insert events.

I know that I never get much in the way of support for this approach
when I describe it, but it has been the easiest way for me to
address these kinds of problems over the last 16 years I've been
developing in Access professionally.

I think it just overcomplicates your coding if you have to account
for both additions and editing in the same form.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"Jeanette Cunningham" <(E-Mail Removed)> wrote in
news:4c6f4620$0$28665$(E-Mail Removed):

> And after you add the new record to the underlying table, do you
> then open the edit form so the user can fill in any other fields
> for that record?

Yes, exactly.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

Yes, it does. When the before_update is cancelled, the .MoveNext (or
whatever) sends a message that it cannot complete. If necessary, I'll
re-create the situation so I can tell you the exact message.

"Rick Brandt" <(E-Mail Removed)> wrote in message
news:i4mkmf$vf8$(E-Mail Removed)...
> LAS wrote:
>
>> But if my application works best to do some validation after all the data
>> has been entered by the user (and there are some reasons for that
>> sometime),
>> how does one validate? I understand how to validate control by
>> control,
>> but my question is specifically how to deal with the failure if
>> validation
>> was in the before_update event of the form.
>
> In the BeforeUpdate event you run your test code. When there are problems
> you display a message to the user and cancel the update. It does not
> matter
> what action triggered the update. It will not even be attempted if you
> cancel the update event.