Hi again. You say that if the main or sub form is dirty, then you want to ask the user if he wants to save.
I haven't been very succesfull in explaining access behavior before, so lets make a little example. You enter a record on the main form, then go to the subform and enter three records. After that, you enter another record in the main form and another five records in the subform. In the fifth record of the subform, the little pencil icon is shown on the record selector indicating unsaved record.
If you perform a dirty check on both the main and sub form, it wil be true. So you ask the user whether he wants to save. Well the user selects no, then what.
The first record in the main form with it's three records in the subform are alredy saved, and can't be undone thru a me.undo. Unless you use some event on the controls, or perhaps the forms before update you have no control whatsoever on whats saved, partial or not (well, exept table level/control level validation rules, required property of the field).
Ok, back to the last record on the main form with it's five records in the subform. The record in the main form is alredy saved (an observation you made yourself when experimenting with the forms before update event "
On the form is a sub-form, and as soon as I tab or click to a subform field, all the data I've entered in the main form fields disappears."

. The four previoud records in the subform (only the fifth record has the "unsaved"/pencil) are alredy saved.
So if you issue an Me!MySubForm.Form.Undo and Me.Undo, only thing happening, is that the fifth record in the subform get's undone.
If you want control over whats saved in the main form, you will have to trap for it before you enter the subform, else the record is saved without any checks.
To check for this, you could use code either on the individual controls to prevent empty/wrong data or using some form event. Using events on individual controls might be a bit dangerous, because a "pesky" user might avoid entering anything in a control by just clicking in another control, so you'll probably need to use a form event. The only "bombproof" form event to use if you want to prevent the saving of a record given certaion validations, is the previously mentioned, and tested, before update event of the form.
Ok - if the intention was to "undo all changes" when the user selects no to cancel, then you'll have to delete the record(s) that's been entered. Should that be only the current record in the main form and the assosiated records in the subform or should it be all the records in the main form entered in current session with assosiated records in the subform? If the latter, how would you determine which records where entered now?
So - back to my initial reply: "
This question is a bit larger than perseived at first glance"
All of the above is doable in unbound form (but as stated by MichaelRed in the other thread
It is a fair amount of keyboard activity) and should also be doable in bound forms. But there are a lot of considerations to make when coding.
When I started working with Access, a collegue gave me some advice to handle situations like this. You mustn't consider this a rule, but I think it would ease up on some of the issues involved here.
"Never allow the user to enter data in both the main and sub form when using such structures and datavalidation is needed"
How - use a single form to enter the "main form data", use the level of validation needed (for instance the before update of the form). When the record is verified and saved, allow the user to open another form to enter the "sub form data". In such cases, I often use a main/sub structure so that the user have all information regarding the "main recor" available, but I leave the main form controls disabled/locked or similar. I think this appraoch might also be more agreeable considering your own description of your coding skills. Again, it's not my intention to offend.
Roy-Vidar