none
Eliminating save form upon selecting subform... RRS feed

  • Question

  • I have a form that contains a subform.

    Is it possible to bypass the save when navigating to the subform and only saving the "main" record when I'm ready - after I'm finished editing the "main" form.

    As I'm writing this, I wonder - could I make the subform "read-only" such that I the main form never really loses focus?


    Thanks for your help!!

    Tuesday, April 5, 2016 10:03 PM

Answers

  • You quite much have to save the main form, since it might be a new record, and without a save, then the automatic primary key is not generated. Thus when attempting to add child records, there would be no parent table record existing yet to allow adding of those child (sub form) records. So the save is by design, and it cannot be disabled.

    You cannot add child records without setting the foreign key column that relates back to the parent record.

    And since a sub form can have “many” records, then the sub form is going to save each record before you add the next one – as a result, once again it makes sense to have the main form saved. And once again, each child record (sub form record) will require a parent record to relate back to – that parent record needs to exist (and thus in most cases saved before adding child records).

    All forms, including continues forms ONLY edit and work and thus can “verify” one record at a time. Use of a sub form does not change this issue. So in a sub form, each row (not the group) of records will be subject to form events that can verify the one row of data.

    If you need to verify the main form, and say one (or several) rows of data in a sub form say for a total etc., then place a “verify” button on the main form. It can thus do all of the required checking and set a field such as “posted” in the main forms table.

    Here is a screen shot showing such a setup.

    In the screen, a check is deposited for each donor, but multiple accounts to split out the check into different accounts is allowed (a sub form). However, during data entry the phone might ring etc. This setup allows the user to exit and return later.

    And it really hard to create some kind of validation with form events for a master record, and several child records.

    So a “post” button is used, and when hit it checks the records and ensures all data “balances” out. That balance is in fact a donation amount in the main form, and then the “list” of accounts in the sub form that the check is split out to.

    Thus, posting cannot occur until everything balances. This also allows one to work and stop to save their work. And it also ensures that people “post” the data.

    Once I post, I also lock up editing of the data. (this is done by checking the posted flag). The "posting" actually does not post, but verify the data, and then sets posted = true.

    Regards,

    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    Saturday, April 9, 2016 1:33 AM

All replies

  • You can make the main form unbound from a recordset. On Open, make it read data from a DAO recordset into the controls. Then make a save button which opens a DAO recordset and updates fields which have changed.

    If you have trouble with the child if it uses Link Master Fields and Link Child Fields, you can refresh it during the Current event of the parent. Or just set the recordset of the child on the Current event of the parent.

    I don't think making the child read only has anything to do with the parent's Dirty property. (Which is what I believe tells the recordset to commit changes to the table.)
    Tuesday, April 5, 2016 11:09 PM
  • You quite much have to save the main form, since it might be a new record, and without a save, then the automatic primary key is not generated. Thus when attempting to add child records, there would be no parent table record existing yet to allow adding of those child (sub form) records. So the save is by design, and it cannot be disabled.

    You cannot add child records without setting the foreign key column that relates back to the parent record.

    And since a sub form can have “many” records, then the sub form is going to save each record before you add the next one – as a result, once again it makes sense to have the main form saved. And once again, each child record (sub form record) will require a parent record to relate back to – that parent record needs to exist (and thus in most cases saved before adding child records).

    All forms, including continues forms ONLY edit and work and thus can “verify” one record at a time. Use of a sub form does not change this issue. So in a sub form, each row (not the group) of records will be subject to form events that can verify the one row of data.

    If you need to verify the main form, and say one (or several) rows of data in a sub form say for a total etc., then place a “verify” button on the main form. It can thus do all of the required checking and set a field such as “posted” in the main forms table.

    Here is a screen shot showing such a setup.

    In the screen, a check is deposited for each donor, but multiple accounts to split out the check into different accounts is allowed (a sub form). However, during data entry the phone might ring etc. This setup allows the user to exit and return later.

    And it really hard to create some kind of validation with form events for a master record, and several child records.

    So a “post” button is used, and when hit it checks the records and ensures all data “balances” out. That balance is in fact a donation amount in the main form, and then the “list” of accounts in the sub form that the check is split out to.

    Thus, posting cannot occur until everything balances. This also allows one to work and stop to save their work. And it also ensures that people “post” the data.

    Once I post, I also lock up editing of the data. (this is done by checking the posted flag). The "posting" actually does not post, but verify the data, and then sets posted = true.

    Regards,

    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    Saturday, April 9, 2016 1:33 AM