Different Saves (1 Viewer)

Zydeceltico · Apr 3, 2019

What are the differences between:

DoCmd.RunCommand acCmdSaveRecord

And

DoCmd.Close acForm, "main_form", acSaveYes?

Or are there any differences?

Thanks!

Tim

pbaldy · Apr 3, 2019

The save argument in the second is saving design changes, not data. If the form is bound, simply closing it will save the data. The first explicitly saves the data without closing the form.

theDBguy · Apr 3, 2019

Hi Tim. As Paul said, acCmdSaveRecord saves the record (data), while acSaveYes saves the form (design changes) when you close it.

gemma-the-husky · Apr 3, 2019

in passing note that access tries very hard to save records. you can save a record by clicking the pencil if the record selector is active, or by just moving to a new record, or closing the form, or by selecting save record from various menus. the real issue is dealing with a record that currently can't be saved because it is breaking some data requirements. if you actually want to force users to save records in some special cases, its best to do this with an unbound form, but I think this is something that should be used sparingly.

Zydeceltico · Apr 3, 2019

theDBguy said:
Hi Tim. As Paul said, acCmdSaveRecord saves the record (data), while acSaveYes saves the form (design changes) when you close it.

Are either of you able to give me an example of when I would want to save design changes during the process of collecting data? COnditional formatting or something else?

theDBguy · Apr 3, 2019

Zydeceltico said:
Are either of you able to give me an example of when I would want to save design changes during the process of collecting data? COnditional formatting or something else?

Hi. Unfortunately, I won't be able to give you any examples because I believe you shouldn't be making any form design changes with a deployed application. All design changes should be done on development copies of your application. What sorts of design changes are you making now while the users are entering data on your form?

pbaldy · Apr 3, 2019

In my view, never. I make necessary changes in design view. I can't recall ever having a situation where design changes were made/saved in use.

Zydeceltico · Apr 3, 2019

gemma-the-husky said:
in passing note that access tries very hard to save records. you can save a record by clicking the pencil if the record selector is active, or by just moving to a new record, or closing the form, or by selecting save record from various menus. the real issue is dealing with a record that currently can't be saved because it is breaking some data requirements. if you actually want to force users to save records in some special cases, its best to do this with an unbound form, but I think this is something that should be used sparingly.

My biggest related challenge seems to be how to "Close Without Saving" Or "Undo and Exit." I struggle with both of these conditions.

Very often is the case that our workflow requires that I open two forms: Form1, add some data, click a button on Form1 to open Form2 (add some data that is ancillary to the data collected on Form1), click a Save button to save both records AT THAT POINT (in other words leaving Form1 dirty rather than saved when focus is changed to Form2) - OR -

Same process but get to Form2 and realize I need to Undo data on Form2 AND Form1 and start over.

Saving (intentionally rather than automatically), Undoing, and Closing Without Saving are all challenges at the moment.

My original question is because I've gotten myself confused with which approach I should be learning about working with Records - as opposed to design - I think.

Someday.....someday......in the interim I'll just keep chugging along asking questions! Thank You Everybody

Zydeceltico · Apr 3, 2019

theDBguy said:
Hi. Unfortunately, I won't be able to give you any examples because I believe you shouldn't be making any form design changes with a deployed application. All design changes should be done on development copies of your application. What sorts of design changes are you making now while the users are entering data on your form?

I'm not making ANY. I happen to agree with you that I shouldn't be making form changes on a deployed application - - which then begs the question of why have that syntax available at all?

When does someone need code to make design changes? I am asking sincerely because I know so little that I would really like to know. I have no opinion. Just trying to understand.

Like I said - - I find the two different syntactic phrases confusing.

Zydeceltico · Apr 3, 2019

pbaldy said:
In my view, never. I make necessary changes in design view. I can't recall ever having a situation where design changes were made/saved in use.

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

DoCmd.Close acForm, "main_form", acSaveYes

pbaldy · Apr 3, 2019

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

DoCmd.Close acForm, "main_form", acSaveYes

No, in my apps the code would be:

DoCmd.Close acForm, "main_form"

theDBguy · Apr 3, 2019

Zydeceltico said:
I'm not making ANY. I happen to agree with you that I shouldn't be making form changes on a deployed application - - which then begs the question of why have that syntax available at all?

When does someone need code to make design changes? I am asking sincerely because I know so little that I would really like to know. I have no opinion. Just trying to understand.

As for times when someone might make design changes at runtime, it is possible, in some cases, where developers opt for some sort of a "dynamic" form, which means its design has to be modified based on users' needs. For example, let's say the form is to mimic a particular hard copy paper form where there is a space for multiple items of a particular piece of information. But to save screen space, the developer decides to present only on control to accept the first piece of information and provide a button to "add" more controls, if the user needs to enter more data. This is just a quick example, which can be solved by using a subform, but just shows you why the option is available because someone might decide to use it that way.

Like I said - - I find the two different syntactic phrases confusing.

In the first code sample, you're not closing the form; instead, you're explicitly telling Access to save a record. The second code sample is where you're closing a form (whether it is dirty or not). In summary, the first option (acCmdSaveRecord) is only available when saving a record, and the second option (acSaveYes) is only available when closing objects (DoCmd.Close).

Zydeceltico · Apr 4, 2019

pbaldy said:
No, in my apps the code would be:

DoCmd.Close acForm, "main_form"

It seems to me that I may have been "wasting my time" trying to save records since Access does it automatically and maybe I should actually be more focused on controlling the timing of when Access saves records or undoing them all together when necessary. Does that seem logically appropriate?

Solo712 · Apr 4, 2019

pbaldy said:
In my view, never. I make necessary changes in design view. I can't recall ever having a situation where design changes were made/saved in use.

I suspect the facility of saving design changes at run time was meant above all for projects where controls are built dynamically during a session.

Cheers,
Jiri

June7 · Apr 4, 2019

I have used acSaveYes in only one case. To save design changes to a report. I had issues with a report running very slowly because of code setting graph properties. For some reason it ran much faster if I first opened in design, set the graph properties, saved report then sent direct to printer. It was very weird.

Frothingslosh · Apr 4, 2019

Zydeceltico said:
Are either of you able to give me an example of when I would want to save design changes during the process of collecting data? COnditional formatting or something else?

I've never had to do this, since my department's policy is to have users download a new copy of the front end every time they open the app, but I can think of one case where this would be acceptable:

Let's say you have a main form/subform setup (or even just one form), where the bulk of the data is displayed in datasheet mode. There could be situations where different users only care about seeing specific columns.

In datasheet mode, you are able to show and hide columns, add your own filters, re-sort based on the columns of your choice, etc. These all count as design changes. As long as they are running from local copies, then if you are NOT forcing a fresh download every time they launch the app, you might consider allowing users to save their changes so that the form's output, which they have already spent time customizing for their needs, remains constant for each user from session to session.

This can be a better solution than creating a different near-identical form for each user or type of user, especially if they will still occasionally need to see the data they normally hide.

MajP · Apr 4, 2019

Code:

In datasheet mode, you are able to show and hide columns, add your own filters, re-sort based on the columns of your choice, etc. These all count as design changes. As long as they are running from local copies, then if you are NOT forcing a fresh download every time they launch the app, you might consider allowing users to save their changes so that the form's output, which they have already spent time customizing for their needs, remains constant for each user from session to session.

This can be a better solution than creating a different near-identical form for each user or type of user, especially if they will still occasionally need to see the data they normally hide.

That example I would disagree with. Opening an access database in design mode at run-time is a really unstable thing to do, and you are begging to corrupt your front end. In the thousands of DBs I have developed I have never found a need to design at run-time, and would argue that if you need to then you have designed the application wrong or there is a better solution. To customize settings of a datasheet you would simply save those settings to the users local settings table and then you can hide, sort, and filter a datasheet.
I would be curious if someone has built a real application for a customer that required design changes, and that there was no other approach. Now I have built many forms via code and saved those so you need those methods to programmatically save design changes. However, I would never deploy an application that makes run time design changes.

Frothingslosh · Apr 4, 2019

I never said anything about opening it in design mode.

If you open in DATASHEET mode, they can hide and unhide columns, sort, filter, and the rest, all of which are counted as design changes despite not being in design mode. If your user is running a persistent local copy, there's no real reason NOT to allow them to save their changes.

And datasheet mode is ridiculously common for subforms. Are you saying you've never once used that for a subform?

If you nuke the ribbon and the right click menus and then put similar functionality back in via VBA (instead of building your own right-click menu, anyway), then you're really just reinventing the wheel.

Frothingslosh · Apr 4, 2019

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

Changes users make to the display here prompt a save dialog when they attempt to close the form (unless you take steps), and there's often no harm allowing them to save their changes if they're using a local copy.

Zydeceltico · Apr 4, 2019

Frothingslosh said:
I've never had to do this, since my department's policy is to have users download a new copy of the front end every time they open the app, but I can think of one case where this would be acceptable:

Let's say you have a main form/subform setup (or even just one form), where the bulk of the data is displayed in datasheet mode. There could be situations where different users only care about seeing specific columns.

In datasheet mode, you are able to show and hide columns, add your own filters, re-sort based on the columns of your choice, etc. These all count as design changes. As long as they are running from local copies, then if you are NOT forcing a fresh download every time they launch the app, you might consider allowing users to save their changes so that the form's output, which they have already spent time customizing for their needs, remains constant for each user from session to session.

This can be a better solution than creating a different near-identical form for each user or type of user, especially if they will still occasionally need to see the data they normally hide.

That seems like a very good reason.

Different Saves (1 Viewer)

Registered User.

Wino Moderator

I’m here to help

Super Moderator

Registered User.

I’m here to help

Wino Moderator

Registered User.

Registered User.

Registered User.

Wino Moderator

I’m here to help

Registered User.

Registered User.

AWF VIP

Premier Pale Stale Ale

You've got your good things, and you've got mine.

Premier Pale Stale Ale

Premier Pale Stale Ale

Attachments

Registered User.

Similar threads

Users who are viewing this thread