Do not save when closing form ?

S

SpookiePower

I have made a form which shows data in textboxes.
If a user edit the text in these textboxes and close the form,
then the changes will be saved to the table. But how can
I do it so that closing the form, not will save the changes ?

I have made a "save-button" and I want the user to use this
button to save the changes.



www.photo.activewebsite.dk
 
A

Allen Browne

Access automatically saves the record when the user does any of the
following:
- moves to another record
- applies a filter
- changes the sort order
- chooses Save Record from the Records menu
- presses Ctrl+F4, Alt+F4, Alt F+C, or Alt F+X, or Shift+Enter
- closes the form, or closes Access.
and so on.
There are also bunches of ways things that can trigger the saving
programmatically.

The only way to catch them all is to use the event Access exposes to you
before the record is saved: the BeforeUpdate event of the form. Cancel this
event if you do not want the record to save.

Of course, the best solution would be to move your code into the
Form_BeforeUpdate event. It will then be run whenever the record is about to
be written to the table. You can validate anything you wish, cancel the
event, and undo the form if you are not happy with the results. And you have
not tied the user into that horrid straightjacket of "save only by clicking
my button" which just screams that the developer did not understand how to
use the Access events.

This example ensures the EndDate is not before the StartDate, and warns the
user if they left the Surname field blank:

Private Sub Form_BeforeUpdate(Cancel As Integer)
Dim strMsg As String
If Me.EndDate < Me.StartDate) Then
Cancel = True
MsgBox "Cannot end before it begins
Else
If IsNull(Me.Surname) Then
If MsgBox("Save without surname?", vbYesNo) = vbNo Then
Cancel = True
'Me.Undo
End If
End If
End If
End Sub
 
S

SpookiePower

Thanks for your help.


Allen Browne skrev:
Access automatically saves the record when the user does any of the
following:
- moves to another record
- applies a filter
- changes the sort order
- chooses Save Record from the Records menu
- presses Ctrl+F4, Alt+F4, Alt F+C, or Alt F+X, or Shift+Enter
- closes the form, or closes Access.
and so on.
There are also bunches of ways things that can trigger the saving
programmatically.
Click to expand...

I did not know that it works this way.

I'll try to work it out.
 
H

HKComputer

Grief. I thought I had a bullet-proof form. I built mine by
disabeling and enabeling certain controls but I see now that users
could still accidentally save a record using some of the above
mentioned methods.

The system I'm using writes a value to a hidden textbox when they press
edit, such as "Edit1". It remains there until they press save. In the
meantime, if the user attempts to exit or switch forms, it will prompt
him to save, based on the value my logic finds in the hidden text box.
This now seems flawed to me.

Is is possible to remove all native menus and toolbars from access and
have only my own? This could prevent some of the scenarios listed
above.
 
R

Rick Brandt

HKComputer said:
Grief. I thought I had a bullet-proof form. I built mine by
disabeling and enabeling certain controls but I see now that users
could still accidentally save a record using some of the above
mentioned methods.

The system I'm using writes a value to a hidden textbox when they
press edit, such as "Edit1". It remains there until they press save.
In the meantime, if the user attempts to exit or switch forms, it
will prompt him to save, based on the value my logic finds in the
hidden text box. This now seems flawed to me.

Is is possible to remove all native menus and toolbars from access and
have only my own? This could prevent some of the scenarios listed
above.
Click to expand...

Stop swimming upstream :)

What you are attempting is not a requirement. You might think it is, but it is
not. Working *with* Access is a lot easier and more productive than trying to
make it behave in non-standard fashion.

Teach your users to press <Escape> and give them the ability to delete unwanted
records. Otherwise if you want a disconnected (thin client type) model then use
unbound forms. It's a lot more work for questionable benefit, but if that is
the behavior you want it is the best way to achieve it.
 
Top