control if data is saved to a table via form (1 Viewer)
- Thread starter MilaK
- Start date
- Local time
- Yesterday, 21:50
- Joined
- Feb 28, 2001
- Messages
- 27,148
Some thoughts on the matter. First, Beetle is right about using the BeforeUpdate event to decide whether to allow the update. That works because BeforeUpdate includes the Cancel option and thus you can stop updates.
Second, look into the command-button wizards, which have form options for Save, Undo/Cancel, CreateNew, and Delete based on button-clicks. I have used these extensively.
What I did for the "Save" feature with the "BeforeUpdate" event in place is that on any FormCurrent event, I would set a flag (that I called OKToSave) false. If the BeforeUpdate or FormClose events fired, they would test the OKToSave flag and either cancel or allow the event. (Remember, Close implies a prior save.) Of course, if the form was not dirty, there was no problem because there was nothing to be saved.
If the form WAS dirty and I used the Save button, I set the OKToSave flag TRUE and thus the BeforeUpdate just let things happen. That same event is a good place for audit logging if you needed to do that, because you could know who wrote to a particular record, when they did it, and could even know what machine they were on at least in some cases.
This kind of form-level protection is perfectly possible, but remember that you can have issues if you have either nasty or totally stupid users who take extreme measures to not save something AND not undo or cancel something. They can leave you with some problems if their machine goes down without properly clearing up pending changes.
Second, look into the command-button wizards, which have form options for Save, Undo/Cancel, CreateNew, and Delete based on button-clicks. I have used these extensively.
What I did for the "Save" feature with the "BeforeUpdate" event in place is that on any FormCurrent event, I would set a flag (that I called OKToSave) false. If the BeforeUpdate or FormClose events fired, they would test the OKToSave flag and either cancel or allow the event. (Remember, Close implies a prior save.) Of course, if the form was not dirty, there was no problem because there was nothing to be saved.
If the form WAS dirty and I used the Save button, I set the OKToSave flag TRUE and thus the BeforeUpdate just let things happen. That same event is a good place for audit logging if you needed to do that, because you could know who wrote to a particular record, when they did it, and could even know what machine they were on at least in some cases.
This kind of form-level protection is perfectly possible, but remember that you can have issues if you have either nasty or totally stupid users who take extreme measures to not save something AND not undo or cancel something. They can leave you with some problems if their machine goes down without properly clearing up pending changes.
- Local time
- Yesterday, 22:50
- Joined
- Feb 19, 2002
- Messages
- 43,233
When you give the user the choice of saving, not saving, or cancelling (Yes, No, Cancel),
You would use Me.Undo to back out all form changes as well as using cancel to stop the save if the user picked Cancel. If the user just chooses No, you cancel the update but you don't back out all pending changes.
You would use Me.Undo to back out all form changes as well as using cancel to stop the save if the user picked Cancel. If the user just chooses No, you cancel the update but you don't back out all pending changes.
