Why save? (1 Viewer)

[smaviddavid]

Hello,

I have added a save button to my form, and i was wandering what are the benefits of this? As it seems even if enter data and close the form without saving it seems to still appear?

Have i set it up wrong?

 

[plog]

Tell us how you've set it up, including the code behind the button and what you want to accomplish and we can tell you what you've done wrong.

Right now it sounds like an elevator door close button--just there to make people think like they are doing something without any real effect on how things would operate if it wasn't there.

 

[smaviddavid]

Tell us how you've set it up, including the code behind the button and what you want to accomplish and we can tell you what you've done wrong.

Right now it sounds like an elevator door close button--just there to make people think like they are doing something without any real effect on how things would operate if it wasn't there.

<---Your messsage
<-- my head!

Ok, basically all i done is added a button and given it the save form feature. So if thats the 'elevator door close button' is, then i obviously have been doing it wrong! lol. I'm working on database at the moment. i will upload a new copy later and post it.

 

[gemma-the-husky]

you right - you can do this, but you do not need to. access will save records implicitly in all sorts of ways.

note that if you show record selectors, the indicator will become a pencil when the record has been edited. you can even save it by clicking the pencil

 

[missinglinq]

The 'all sorts of ways' that Access automatically saves Records includes

• Moving to a different Record
• Closing the Form
• Closing Access

Access is a Database, not a Word Processor or a Spreadsheet, and the way these three types of apps are used are distinctly different! Databases are frequently used in what is known as a 'production environment.' An operator/user may enter dozens or even hundreds of Records per hour, and may even be paid accordingly, and having to 'save' each Record before moving to a New Record is time consuming, hence the automatic saving.

Placing a Save Button on an Access app

• Is unnecessary
• Requires extra code
• Ticks off experienced Access users by adding a step that isn't needed

Linq ;0)>

 

[speakers_86]

You should become a little more familiar with the events in Access. When it comes to saving data, you would be interested in the FORMS Before Update event. Of course what Missinglinq said is true, but you can test it if you wish. In the form's before update event, place this:

Msgbox "The form is about to save data."

Now you will be notified every time the form is trying to save data. Anytime you are confused about what event is 'firing' or in when order the events fire, you can simply place a simple message box and Access can tell you what's going on behind the scenes.

 

[nanscombe]

The only time I would a specific Save button is if I were reading and writing data via a non-bound form, ie no recordsource.

Save buttons would probably be more appropriate to Web Development these days where it is pressed to submit the data back to the Server.


It's actually difficult to think of an instance where a Save button would needed in an everyday Access environment.

The only scenario I can think of is if someone in a Corporate environment had written a DLL, OCX or Class module which people were obliged to use to talk to a database indirectly.

There could a call to read a records worth of data and another call to update the record, initiated by a Save / Cancel button combination.

ETA: Thinking about this, I think I have used something similar for talking to a MySql database. I could read from the database but I couldn't write it back (due to limitations of the ODBC connector) so I had to create an SQL statement to indirectly update the record via a Save button.

 

[gemma-the-husky]

in many cases, having a button might actually be more confusing

if a user did NOT click it, he might (wrongly) think that his actions were discarded ....

 

[nanscombe]

Of course ... Rollback!

When using an Access front End with an Oracle back End you can turn on Transactions, which temporarily keeps track of any changes that you have made since the last Commit (save).

You would then have a Save button which committed the changes that a user had made and a Cancel button which would "rollback" the database to the state it was before the user changes.

Transactions would be useful if you were making changes to a number of tables in one action. In Access cancelling would only cancel the changes on the last table whereas a Transaction could cancel all of the changes made since the last commit (Save).

 

[vbaInet]

We're really making things hard for smaviddavid talking about advanced topics

smaviddavid, you don't need the Save button on your form. missinlinq explains the different scenarios where data is saved automatically by Access. gemma-the-husky (post #8) gives a con about having a Save button on there. nanscombe (post #7) in his first sentence mentions when a button might be needed in an Access environment (i.e. when you have an unbound form, which in your case isn't).

 

[missinglinq]

We're really making things hard for smaviddavid talking about advanced topics

I agree! I enjoy teaching, but try very carefully not to overwhelm obvious newbies with too much info, especially about advanced subjects in Access.

As professional musicians will tell you, you should always 'play to the audience!'

Linq ;0)>