Well my database is in the user environment. Hooray! But they presented me with a problem that I didn't think of.

The form and the controls are bound to an underlying table. When the user is in the form viewing the records, some have inadvertently change data, moved on the next record without realizing it.

I don't mind if they change the data, because they can update the data anytime in the form, but I need a way to make them aware that the data has changed in the record, do they accept the change, and also have them edit a date field in the form pertaining to the last time a change was made to that particular record.

Would I use a beforeupdate event for this type of action?

As Always very grateful, bph

Do not allow your users to just change data on any form. Make sure that they view their data in reports and use forms mostly for data entry and data edits. Use ADO for data entry/edit forms. This will ensure that your users know that changes are permanent. Never allow a user to change/edit/add data with a form in datasheet view or continuous form

Do not create an application that allow a users to change data in a form by just changing the values while another form makes them click a save button. This creates confusion.

You could use the after update event to warn the user that the record will be changed, but this will fail if you do not use ADO. Access wil make the data edit even if you warn the user.



Sal

Sal, Thanks for the info.
I have a form which is strictly for data entry. But there's a need for the user to edit data using the form which is tied to existing records table. There are about 50 different controls on the form where the user can make a change. ADO?? whole new ball game for me.

I rarely ever use continuous forms because they present lots of formatting problems (they usually behave all or nothing instead of per record). However, there are times when I let people edit things in datasheet view. In fact, the datasheet view is much more convenient and user-friendly in some cases. For example, if someone is entering stack parameters for an output stack and they're entering stack no., diameter, height, flowrate, etc. To see them lined up in datasheet view is more intuitive than one at a time on a form.

They way I avoid accidental saves is that the form and subform (datasheet view) are read-only until an EDIT button is pressed. At that point a label on the upper right of the form header changes from a green "VIEW" to a red "EDIT". When the user moves to the next record, everything reverts to read-only again.

Hey! I hit 200 posts! I'm a member now! I'd like to thank the Academy...

Greg Serrano
Michigan Dept. of Environmental Quality, Air Quality Division

Congrats! I feel I have somehow helped make this possible.

Back to work. The coding oif the 'edit button' takes place where and how.

How about using the dirty event?

bph

 I'd like to thank all the little people that... JUST KIDDING! JUST KIDDING! :D

Well, no. Since the form opens read-only you can't dirty it. You have an EDIT button somewhere and you put the code on the button's On Click event.

Basically, on the form's On Current event you have:

If you have a subform as well, then:

On the button's On Click event you just set them all to true.


Greg Serrano
Michigan Dept. of Environmental Quality, Air Quality Division

Thanks! Brings tears to my eyes to think I was there when it happened.