How are ya p27br . . . .

Access will not allow a record to be saved if any Required fields are empty. In short . . . . your stuck wth the rules you set.

  See Ya! .  .  .  .  .  .

Are you entering data and THEN trying to go to a new record? If so, try reversing the order.... go to the new record first, then enter the data.

How are ya randy700  . . . .

p27br said:

Quote:

if I click cancel I get the error 2105. that is if i don't fill in all the required fields

Am I missing something here?

  See Ya! .  .  .  .  .  .

Hi!

The 2105 is the "You can't go to the specified record" message, if I'm not mistaken.

What happens is that trying to move to the new record, an attempt to save is made, which invokes the before update event. When you cancel the before update, well, the goto new record is cancelled, and this is Access way to tell you that.

One way to avoid it (the message), is to use a simple errorhandling routine, perhaps something like this:

Private Sub cmdNew_Click()
on error got MyErr
    DoCmd.GoToRecord acActiveDataObject, , acNewRec
    Call CarryOver(Me)
MyExit:
  exit sub
MyErr:
  if err.number<>2105 then
    msgbox err.description
  end if
  resume MyExit
End Sub

Roy-Vidar

Hay Roy!  . . . . . How are ya . . . .

An honor to have you stop by!

I'm well aware of the Error Code 2105 and have had to deal with it in some of my designs. I was lead to believe by the post origination that Required was set as necessary in tables. I setup a sceanrio and got what I expected . . . . . notification of required fields and record not saved! Besides the fact that I expected Required to be the first alert . . . .

My query is simple . . . . how were you able to see that Required was not set?

  See Ya! .  .  .  .  .  .

Hello to you both and thanks for taking interest in my query.

TheAceMan1 : you are correct to say that there are some required fields not being filled in. But the problem is not there. If I fill in all required fields, I still get the message. Sorry for misleading you :)

So RoyVidar I followed your suggestion to force access to ignore the error and it fixed the problem. I hope it won't have unexpected consequences in another situation ?

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

RoyVidar  . . . .

Gotcha . . . . . I've been noticing more & more lately that I've been a little to expectant when it comes to reading posts. Could be some kind of fixation on my part. Maybe I need to take a break or slow down.

Anyway cheers!

  See Ya! .  .  .  .  .  .

thanks Roy for making things clearer and for the detailed post