Different Saves

[Zydeceltico]

So - - -- In light of all this valuable insight - - -and given Access constant intent to save data to records, might I often be just as well-served to have a cmdButton labelled "Save" but whose underlying code is DoCmd.Close rather than writing out RunCommand.acCmdSaveRecord? I mean - I can see where I would want to save a record at a specific point in the workflow other than when the user clicks a "Save" button and that would seem an appropriate condition to use acCmdSaveRecord but otherwise just use DoCmd.Close on all of my "Save" buttons as I'm assuming that clicking the "Save" button will generally be very intentional. If a mistake is made, I could offer a different option on a different button to delete previous record I am assuming?

 

[theDBguy]

Hi. DoCmd.Close closes the form object. If that's what you want to happen, then the caption on the button should be more appropriately labeled "Close" or "Exit" rather than just "Save." You could consider maybe using "Save and Close."

 

[MajP]

In fact, here's what I'm talking about. Note that this is NOT design mode.

I agree these are not in design mode, but also these are not design changes. These are available customization. The OP's original question had to do with design changes at runtime. I concur with DBGuy, and I can not think of a reason to do it. IMO the feature is available at design time so that you can write code to build and save a form. I might be wrong but do not believe the intent was so that people should make design changes at runtime. If someone feels it is needed I would say there is likely a better way. However, I would be interested in an example where someone has deployed this and what the reason was, and to be proved wrong.

 

[Zydeceltico]

Hi. DoCmd.Close closes the form object. If that's what you want to happen, then the caption on the button should be more appropriately labeled "Close" or "Exit" rather than just "Save." You could consider maybe using "Save and Close."

The many instances I'm thinking of are in fact "Save and Close" scenarios.

I suppose it is much better practice to use the acCmdSaveRecord code followed by DoCmd.Close because it is obviously more intentional.


I have many instances where a main form calls a detail form for more data to be added - and the main form stays open until the second form is saved and closed.

When does the data in a form actually get written to a table? I'm trying to get a clear picture of how I can "pause" the data on the first form from being recorded until I click "Save and Exit" on the second form.

 

[Zydeceltico]

I agree these are not in design mode, but also these are not design changes. These are available customization.

That makes even more sense. Thank you.

 

[theDBguy]

When does the data in a form actually get written to a table?

I am quoting the first statement from this MS article

When you move to the next record on a form or close a form, Microsoft Access automatically saves any changes that you have made to the current record.

 

[Zydeceltico]

I am quoting the first statement from this MS article

So apparently as long as I don't close Form1 or intentionally Save it, it is not yet saved when I open Form2 from it and while I am working with Form2.

In other words even after I click a button on Form1 to open Form2, Form1 is still in BeforeUpdate mode and the data is not yet recorded. That's what I am reading anyway.

 

[theDBguy]

So apparently as long as I don't close Form1 or intentionally Save it, it is not yet saved when I open Form2 from it and while I am working with Form2.

In other words even after I click a button on Form1 to open Form2, Form1 is still in BeforeUpdate mode and the data is not yet recorded. That's what I am reading anyway.

Should be easy enough to test it. Also, I am not sure the article I found is comprehensive. I seem to recall moving the focus from one form to another also triggers the auto-save feature, but I can't find anymore references at the moment.

 

[Zydeceltico]

Should be easy enough to test it. Also, I am not sure the article I found is comprehensive. I seem to recall moving the focus from one form to another also triggers the auto-save feature, but I can't find anymore references at the moment.

I found this article and example that appears to "force" the use of a "Save" button. I need to try it now.

https://bytes.com/topic/access/insights/891249-how-stop-bound-forms-updating-automatically

 

[gemma-the-husky]

So you've never ad a reason or purpose for using this phrasing or something similar?

DoCmd.Close acForm, "main_form", acSaveYes

Not only should you never need this, in most cases with many users, you would issue a accde/mde rather than a accdb/mdb, in which case the user cannot make design changes at all, so it just wouldn't arise.

 

[gemma-the-husky]

If you add record selectors to your form you get a vertical bar down the left. Its more normal to have record selectors with continuous forms, but can be used on single forms.

Anyway, with a dirty (edited) record you see a pencil, rather than a black triangle (arrow). Once the pencil changes to a triangle, the record has been saved. So you can get a vsual indicator of when the save happens.

 

[Zydeceltico]

I am SO excited! I just wrote my first major (for me) code from a blank screen!

Private Sub cmdSaveLineStop_Click()
    If CurrentProject.AllForms("frmInspectionEvent").IsLoaded Then
        DoCmd.RunCommand acCmdSaveRecord
        DoCmd.Close
        Forms!frmInspectionEvent.Requery
    Else
        DoCmd.RunCommand acCmdSaveRecord
        DoCmd.Close
    End If
End Sub

Works exactly as I want it. A light bulb turned on - finally!

Now - I use that exact code in about 10 places. Can I turn it into a public function from a Standard Module and call it whenever I need it and clean my class modules up?

Just wondering.

Thanks!

Tim

 

[Zydeceltico]

Anyway, with a dirty (edited) record you see a pencil, rather than a black triangle (arrow). Once the pencil changes to a triangle, the record has been saved. So you can get a vsual indicator of when the save happens.

That's really helpful. Thanks!

 

[MajP]

Yes, however, the docmd normally has other arguments. If it is run from the active window it knows what to save and close. But called externally you may need to tell it what form.
To see what I mean
https://docs.microsoft.com/en-us/office/vba/api/access.docmd.close
I normally directly specify. If not you may docmd.close and the wrong thing closes.

Here is a hint.

Public sub SomeSub(frm as access.form)

end sub

called from the form itself
someSub Me

Called from another form
someSub Forms("formName")

one other thing if it happens all the time remove from inside the if check. You save and close all the time

Private Sub ()
    DoCmd.RunCommand acCmdSaveRecord
    If CurrentProject.AllForms("frmInspectionEvent").IsLoaded Then
        Forms!frmInspectionEvent.Requery
    End If
    DoCmd.Close
End Sub

 

[Zydeceltico]

Yes, however, the docmd normally has other arguments. If it is run from the active window it knows what to save and close. But called externally you may need to tell it what form.
To see what I mean
https://docs.microsoft.com/en-us/office/vba/api/access.docmd.close
I normally directly specify. If not you may docmd.close and the wrong thing closes.

Here is a hint.

Public sub SomeSub(frm as access.form)

end sub

called from the form itself
someSub Me

Called from another form
someSub Forms("formName")

one other thing if it happens all the time remove from inside the if check. You save and close all the time

Private Sub ()
    DoCmd.RunCommand acCmdSaveRecord
    If CurrentProject.AllForms("frmInspectionEvent").IsLoaded Then
        Forms!frmInspectionEvent.Requery
    End If
    DoCmd.Close
End Sub

That's much more succinct! Thanks