Bob,
van is *absolutely* correct. in principle you should test the validity of
the data in the form Before Update event of the from. However, in
addition
to the Close event the record is automatically updated when move you move
to
another record or you enter the subform.
This being the case an all encompassing "Before Update" is not suitable in
this case and you have to validate in a different way.
The problem of moving to another record can be solve by disabling the
*all*
the buttons that get you out of the record (incl that that closes the
form)
until all date in the record is validated.
Be aware that taking this approach is not fool-proof, as you can still
move
to another record using the mouse wheel - there is command to disable the
wheel, but there are ways of doing it
As you do have a sub form the record will on the main form *and* your
validation tests that the subform must have an entry in it, if you
validate
On Before Update event, you will not be able to enter the subform when it
is
empty because you will not be able to update the record beforehand. You
can
overcome this problem by crating a dummy owner, say, "Unknown", Or "To be
advised" etc. and set that owner as you default value in the subform (or
add
it to the sub form if there are no owner(s) entered
I presume that a horse must have a name, If the horse does not have a name
(yet), you want to refer to him by both his parents and his owner (date of
birth?, if so can a dam have twins?)
I also presume that the critical problem, may be when you add a new horse,
but
bear in mind, that the horse data which was valid can render it invalid.
Regards
Jacob
Van T. Dinh said:
I think it would be the developer's responsibility to prevent inconsistent
saving of data ... Users will make mistakes and programmers / developers
are supposed to "trap" these mistakes and redirect the user to the correct
procedure (as much as possible anyway).
BTW, the correct place to prevent the unintentional saving of record is
the Form_BeforeUpdate Event. Before the Form can be closed, the data
need
to be updated into the Table(s) and therefore the BeforeUpdate Event will
fire. Trapping this will trap bothe the Form's Close button and your
CommandButton.
--
HTH
Van T. Dinh
MVP (Access)
Bob said:
Oops to bad for them they should be clicking [Back to main Menu] did
strike a little bug it would save if I had the [OwnerID & cbMothersName]
Regards Bob Vance