Question To save or not to save

[Groundrush]

What would you do?

This isn't Access related so not looking to solve anything but interested in finding different opinions on something that was not a problem until too many people got involved

The question is, How would you programme your system to save records, would you use save on exit without a warning message or would you prefer that the user has to be aware & click on a save button?

I have never had an issue with this in the past because I have always set my databases to save automatically when you enter your data.

I prefer this method because if you forget to click on the save button it will still be saved or if you quit the application before saving it will save.

I am now being challenged to this by some stating that they prefer that you have to click on a save button to confirm the changes, my argument is that users are forgetting to save resulting in empty records....

We did suggest having a message prompt to warn you before you close but the problem is that this particular software allows many different tabs open at any one time and it will be annoying having a dozen or so repetitive messages each time you close a tab.

I still believe that having data automatically save is the better option because if you did not want something to be saved to the record then don’t type it in.


What do you think?

 

[DCrake]

I you consider how Windows handles this you will no doubt of seen forms where you have the following

Ok - Cancel - Apply command buttons

Ok - saves changes and exits
Apply - saves changes - does not exit
Cancel - exits no changes since last apply.

If you are using unbound forms then this is the policy I would adopt
Bounds forms are slightly different as they always imply that changes are wanted. Having an undo feature is fine if you want to discard all changes. When having forms open try to contains the changes to specfic tables so there is no cascading effects. And don;t forget to use the Dirty test.

Somewhat concise but its a start for you.

David

 

[CHSBK]

Hi

I can see an arguement for both sides of this discussion, but ultimately, I think that which ever method you employ in your application, users (even those who oppose your final decision) will very quickly get used to it.

I still believe that having data automatically save is the better option because if you did not want something to be saved to the record then don’t type it in.

What happens if, in a busy environment, something (not too heavy) hits the keyboard, changing some of the information, the user isn't aware that this has happened and, when exiting, inadvertently saves the changes?

 

[Groundrush]

What happens if, in a busy environment, something (not too heavy) hits the keyboard, changing some of the information, the user isn't aware that this has happened and, when exiting, inadvertently saves the changes?

I think something like this would not happen very often so I would rather apply rules to what is likely to happen the most, like being able to create/update a record naturally

If I was continuously given similar scenarios like this one to answer then I would simply respond by saying that this could also happen using the other saving methods, Infact in some cases the damage could be far worse as the whole record could be lost if something accidentally hit the keyboard & closes the application down without saving the changes.

 

[Atomic Shrimp]

My preference is to allow the user to interact with the data in a bound form and let Access handle the saving of records.

If necessary (usually in justified type one-record-per-view forms) I'll give the user read-only access to the data until they click an 'edit' button. (this also makes it simple if some users are not allowed to edit the data - you just don't let them see the button).

In cases where data is being routinely appended to the database (for example, orders, invoices, event records, etc) I usually let them enter it into a temporary table (local to the front end) and only append to the database when they click a 'submit' button, or some such.

The problem of inadvertent data change can happen regardless whether you let them edit interactively, or make them click 'apply' - for data where changes are critical, it's probably a good idea to log them all - for example on the BeforeUpdate event of a critical field, append a record to a text field in an audit log to the effect:
"Fieldname: [whatever] changed from: [Old Value] to [Value] by user: [userID]"

 

[NewShoes]

I'm interested to know how I would go about setting Access to not save automatically?

 

[Alisa]

I'm interested to know how I would go about setting Access to not save automatically?

Wouldn't we all . . .
Unfortunately, it is impossible.

 

[Banana]

Wouldn't we all . . .
Unfortunately, it is impossible.

I would respectfully disagree. I do think it's possible.

We can use form's BeforeUpdate to cancel the save operation and reset the record into its original state.

Heck, we could just use a save dialog where Yes does nothing and No is actually a Undo.

Now, if ACID is important, then I would say it's probably easier to load the record into a temp table and commit them back to the permanent table only upon the button's click.

 

[Alisa]

I would respectfully disagree. I do think it's possible.

We can use form's BeforeUpdate to cancel the save operation and reset the record into its original state.

Heck, we could just use a save dialog where Yes does nothing and No is actually a Undo.

Now, if ACID is important, then I would say it's probably easier to load the record into a temp table and commit them back to the permanent table only upon the button's click.

Yes you are right Banana, there are plenty of work arounds. I meant in the literal sense, there is no setting in Access where you can choose save automatically or don't

 

[Banana]

What would you do?

To me, I think there is a good reason for not asking to save. If I'm a data entry operator, I want my workflow to be fast and efficient. Therefore if I'm handed a stack of paper and asked to enter them, I sure as hell will expect that the program I'm using to enter data lets me tab into fields, enter data, tab to next field, then hitting the enter to advance to new record.

A dialog may force unnecessary work because I may have to break out of the pattern to get the mouse to click 'OK' or 'Yes' or whatever, or elict a extra tab(s) & enter, which still doesn't take away from the fact that I had to waste a second on the dialog and for every record, it can add up.

As a developer, I believe it is my responsibility that I help maximize the productivity and to that end, I actually avoid using any kind of messagebox and rather using SetFocus, Conditional Formatting and Status Bar Text to communicate with users if the record failed the validation due to mangled data. Even better if I do not use Setfocus and merely raise a visual warning so the user can correct themselves when they want to without being railroaded.

There are indeed times when it makes more sense to require an explicit save rather than implicit saves. One common scenario is when we want to be able to work on a batch as an unit and we don't want to save each part immediately until we are satisfied with the batch. Even in those cases, though, I find myself using temporary tables or disconnected recordsets to provide such functionality and require that the users make a explicit choice to save or discard the change at end of the batch. Even so, in some cases, closing the form is good enough indication that the users wants it saved. If it doesn't apply, then I don't allow them to close the form using the red X, providing my own buttons which states clearly what it will do (e.g. "Save and Close" & "Discard & Close"). Again, the point being to minimize the work and frustration. I mean, doesn't everyone have those of time when they're presented with a dialog, "Um, yeah, I am pretty sure I want to do that. In fact that's what I just click, so kindly bugger off and do what I tell you to do, mmmkay?"