Solved Form/Subform prevent saving data on main form when changing focus on subform (1 Viewer)

[Romio_1968]

Hello there

The Form called Add_Frm_Title is opening from the main menu using the "Adauga Titlu" button on the Main landing form.

Add_Frm_Title contains a subform called TtileAuthor_Junct_Sfrm
Add_Frm_Title is linked to Title table and the Subform to a Junction Table, accessed via a query, that adds existing or new authots to the Title_ID

There are two behaviours here that bugs me.
The user must first have to fill all the required fata on the Add_Frm_Title. When trying to move focus on the subform, the Add_Frm_Title is tested for the required data, and only when all fields (controls) are properly filled, the control is passed to the subform, allowing the user to start adding data in in.
So here comes the first problem
If the Title does not have an author (there are publications with no author at all), the record in Add_Frm_Title is saved by clicking the button labeled "Salveaza Titlul". After testig the required fields, if everithing is OK, the Title is saved,
But the data is also saved even when the control is passed to the subform, and this is an undesired behavior that I should prevent. The user may change his mind or just roamning on the form and data can be accidentaly saved.
Moreover, this unwanted save leads to an other issue. The process of adding a title is aborted by hitting the New button. If there was no interraction with the subform, the title is not added to the Title table. But if the subform was filled, all the data will remain, in the Title table and teh Junction table (if anything was added)

Anothe annoying thing is related to the same save button.
Beside the fact that the data is actually saved by passing control to subform, in which case the button is redundant, it does not have a clean behavior.
If by any mean I try to add inside the Save button code any kind of instruction to go to a new record, when passing control to the sub, after that unwanted data saving, the main form is reset. This is as much unwanted as the data saving is.
As well, assuming that all the data on the form and sub is properly filled, by cliccking Save all the data remains on the form until the New button is hit. Sure, I can add some "The data was saved, please press New", but is not that clean.

Thank you.
Please don't bother on other issues then those related to the described unwanted behaviours.

 

[bastanu]

Please review the updated file, should work as you describe.

Cheers,

 

[Romio_1968]

Bastanu, actually it doesnt.

When opening a fresh form from Main, works fine until passing control.
If the required fields are not filled, the error message pops up asking to fill them before going to the form.
If all the fields are properly filled, control is passed to the sub, but the title is saved, so the behaviour rests.
I know that this is the defaul way Access works, but I thought that there mau be a solution to prevent data to be autoseved wven changing focus from form to subform. So this issue remains.
Same thing is happening when control is passed from sub to form. The data entered in the sub is saved on the Junction table.
Clicking the half redundant save button will save data, but it doesnt clear the fields.
Moreover, noe the New button crashes the normal behavior.
After clicking it, the fields are cleared and (aparently) the form goes to a new record
But all the validations when passin control to subform are messed. The required fields are filled, but the error message pops. No more highlighted fields, also,

Don't bother to modify the form.
Yoy can just explain the steps, if you find a way to prevent the record autosaving.

Thank you

 

[bastanu]

I' m afraid the only way to move between forms and not fire the BeforeUpdate event is to use unbound forms ...
Cheers,

 

[Romio_1968]

Pat Hartman, thank you for the extended tutoring. It is helpfull, indeed.
Meantime I have a better understanding of how, when and why the records are saved, and modified the code accordingly.
The user wil now not be able to see the child if the parent requirements are not met. That simplified a lot the code, since I don't have to deal anymore with user's chaotic clicking.
As a rookie, I wil not use the modules from the very begining. I will play with subroutines. Sometimes I am using Messages inside just to check for values or behaviours during developing and testing.
Anyway, your way of thinking is neat and your adivice is golden. The reusable modules are now one of my targets. But beiing a rookie as I stated, for now I am avoiding them because it is still dificult to deal with both errors that comes from the subroutin logic itself and the module specifiic errors on the same time. I am starting to implement modules (already doing this) wherever I have a stable subroutine or behaviour that can be repetitive.