Hi again!
p27br:
I don't think you'll get any unexpected consequences using this scenario. This is just dealing with Access urge to tell you what you alredy know, that you've cancelled the goto record method. It's really nothing more than avoiding the message.
But - what can be challenging/funny is when using lot's of events (dependent of/or firing off other events), there's always the chance of "event collisions", events firing events firing events... endless loop/always dirty record... (assigning a timestamp to a control bound to the forms recordsource in the forms after update doesn't necessarily provide the results one expects;-))
However, if you've got required controls/fields, dealing with them too in the forms before update event is encouraged (by me at least) to prevent more default messages.
TheAceMan1:
In the original question, the gotonew record routine and the before update event of the form was presented, and the question related to why the 2105 message pops up when cancelling the before update event of the form.
When I create a new form, create custom navigation buttons (thru the wizard) and use the following two scenarios:
* moveprevious when at the first record, movenext when at a new record
- the 2105 occurs
* moving (in any direction) when the current record doesn't qualify against the table level constraints
- form errors occur, DataErr 3314 (Null), 3317 (validation rule), 3022 (dupes) , 3058 (PK/Index Null) depending on what constraint is not met... But I can't make the 2105 fire.
So to answer the question about how I was able to see that required was not set, I didn't, and I still don't, but since the before update event of the form invokes before the actual save is performed, therefore also before tablelevel constraints are checked, then it wasn't, as I see, the issue here.
So what happens here, is that the save operation is cancelled, thereby cancelling the constraint check and the different form errors. But some methods, like the gotorecord method of the docmd object, "insists" on telling us "the obvious" - we've cancelled the operation;-)
This makes the before update the ideal event of performing datavalidation in bound forms, because you can do operations like this, cancelling the selected action and in stead give the user a more meaningfull message (which control(s) are offending which of the constraints) - and avoid default messages.
I think if this had been a validation issue, controls/fields not matching table level constraints, one would have gotten the form errors prior to the cancelling of the gotorecord method. "The field 'blah blah' cannot..."
Roy-Vidar
