Curious question for Pat Hartman (1 Viewer)

[ShaneMan]

Ms. Hartman,

You have may it very clear on a number of post, that I've read, that checking for required fields and duplicate fields, should be done in the forms BeforeUpdate event and last week, when you helped to try and achieve this on one of my forms, posted back and stated, "I never remove the close box or make forms modal unless they absolutely work."

Here's my question. If I disabled the forms max, min and close and then put my own Close cmdButton on the form and in this cmdButtons OnClick event I did my validations before I allowed the form to go to Close, wouldn't this at least be an OK way of doing it since I'm not allowing any of the forms "closing" events to fire? With BeforeUpdate I'm having to validate and if it doesn't pass, then stop the form from closing and cancel the forms events.

I'm only asking this cause I know your experience level is way above mine and of course I'm using my own close button, and the way you answered me made me think this was not a good way to do it, so I thought I would ask if it is a bad way of doing it and why. I just want to make sure that I'm not creating problems for myself.

Hope this makes sense,
Shane

 

[Pat Hartman]

wouldn't this at least be an OK way of doing it since I'm not allowing any of the forms "closing" events to fire?

Any method that can be circumvented to allow bad data to be saved is simply wrong - sorry. You have a responsibility to your company/client to protect his data to the best of your ability. I have mentioned way too many times how EVERY event except the form's BeforeUpdate event can be bypassed by a network error that makes Access fail or by simply rebooting. I know these are not common events but they are events that happen to me on a frequent enough basis that I would be worried about loosing data. Also, when you put a user into a tight loop when he is trying to close a form and you won't let him, his frustration level increases to the point where he WILL pull the plug. I did, your app forced me to when I was trying to test it for you. If I did, some user will and the bad data will already have been saved. Interfaces shouldn't frustrate people. They always need to be given a way out. If you give him a way out in the click event of your close button, you need to determine if the record he was working on was just added, in which case you want to delete it but if it was an existing record, you want to revert to its previous state. But guess what? You don't have any way of recovering the record's previous state because unless you are keeping an audit trail, each save overlays the previous values making you (or actually the user) SOL.

If I disabled the forms max, min and close and then put my own Close cmdButton on the form and in this cmdButtons OnClick event I did my validations before I allowed the form to go to Close,

If you simply use the correct event for your editing, you don't have to go to these draconion measures to prevent a form from closing. You just give the user the option to fix the data or cancel out with your code in the Form's BeforeUpdate event and THAT'S IT! Simple, straightforward, and most important - foolproof.

You folks would all be amaized at what little code I actually write. The key is learning to write the right code and putting it in the right event where it will have the desired result.