After update event triggered by changing tab

[The_Doc_Man]

@riktek

Update and save have different meanings at a fine level. You can save a record on a form using the appropriate DoCmd.Save action along with the acCmdSaveRecord option. However, if you are going to Update something via a true Update query, you must update using VBA to trigger an SQL action. There will be no event in that case. Also, you can't make a form that actually does Updates based on an Update query. The reason is that an Update query returns no records so cannot be the basis of a form. Therefore you are in an apples-vs-oranges situation. The problem is that in Access, update is both a query type and the effect of a Save action; in the latter case, the underlying record IS updated (lower-case U) - by a Save action, not an Update (upper-case U).

Any form on one of the tab pages, even the first tab page, is just another subform.

With one exception... the main form participates on ALL of the tabs. If you put controls on a Tab control, they show up with and are controlled as part of the main form. If you put a form on a tab then you are right, that has to be in a sub-form control. But it is no different than a sub-form on a main form that doesn't have tab controls. You address tab-resident controls as though the tab didn't exist. Which is why you can't duplicate control names across two or more tab controls on the same form. Same name space.

Switching from one control to another in such a way as to cross tab controls has NO EFFECT on saving a record UNLESS the control losing focus was a sub-form. The presence of a tab control has NO EFFECT on saving the parent record. It is the presence of a populated sub-form control that makes the difference.

 

[riktek]

The presence of a tab control has NO EFFECT on saving the parent record.

No disagreement but that is beside the point, which is that it isn't clear from the OP that the parent record, or form, is in question. He said the "main form," not the "parent form," was on a tab page. A tab control's parent can't be on a tab page. Common usage of course is that "main form" means "parent form" but here, that isn't the configuration described.

 

[riktek]

I suspect Pat knows what she's talking about!

She has made a very clever form which monitors the events and records them as you can see in this video we did together:-

Perhaps but if so, she ought to be able to respond substantively rather than ad hominem.

It's an interesting presentation but I've also studied event progression with equal or greater rigor, so I do, too. Perhaps she might learn something if she paid attention, read closely, and weren't so prickly.

 

[Edgar_]

The issue I have is that the when the user clicks on tab page which contains the main form the afterUpdate event of the main form is triggered before the subform is filled by the user.

Those events were triggered before your user entered the subform if the main form was already dirty. The main form can not trigger the After Update or After Insert events exiting a subform.

As for the tab control, the thing to watch out for is the auto focus. Clicking on a tab shifts focus to the first control on that tab. If the first control is a subform, clicking the tab will enter the subform. As previously mentioned, if you enter a subform while the main form is dirty, the main form record will be saved. To prevent this, add a Before Update or Before Insert event to the main form.

The notification should be sent only after entering records on the suborm and when the users either close the form or save the record on the main form.

The main form afterUpdate event should trigger an email notification

No, you should be using the Close or Unload events to send the email. And if you have a save button, then that button is the smart place to send the email.

 

[Pat Hartman]

You can save a record on a form using the appropriate DoCmd.Save action along with the acCmdSaveRecord option.

acCmdSave didn't used to save the current record but it seems to now. It is supposed to save the changes to the form. Apparently, enough acCmdSaveRecord saves the current record.

Commands that also save the current record as a side-effect

Me.Dirty = False
Me.Requery
Me.Refresh
Closing a dirty form.
Closing the database with a dirty form open

Added a new feature:

Both accmdSaveRecord and acCmdSave now save the current record. That was probably a wise change. Why fight city hall