Warning User of data changes

[Marcus H]

Is it possible to display a message on my field when the user tabs in that they may be about to make changes to the data. I don't want to lock the fields in case data needs editing but i don't want them to actually change stuff by mistake without realising it. I know i can attach a message box macro to the on focus event but it would be really useful if this would only display on edited records and not when i am entereing a new record. Any tips would be most appreciated cheers.

 

[llkhoutx]

Inadvertanent modification of data by a user is common, especially on continuous form screens showing multiple records.

I lock all records, then is a user really wants to edit a record, I have him double click any field to unlock (all records) and then, on current (when the user moves off the record), I then relock all records. You can also modify a field with "LOCKED!" and "UNLOCKED" as the case may6 be so that the user can see what's going on. Alternatively, change the background color of all fields to indicate locked and unlocked.

Also when I add a new record, I unlock so that data can be added and changes made, then on the OnCurrent event (moving off) I relock everythin.

alternatively, on the AfterUpdate event of every field in a record, use a Yes/No message to the user, i.e., "Are you certain that you want to update this field?" Of course, this can be onerous. Locking and unlocking works great.

There's lots of ways to skin this cat.

 

[The_Doc_Man]

I took an alternative approach to this one.

When the user changes focus, I put a tweak in the _LostFocus routine to change the color of the text box from black/white to dark red/pale pink. I also set a global flag that causes COMMIT and CANCEL buttons to become visible (they were there before, just hiding). Then I put a Form_BeforeUpdate trap to force the user to select COMMIT or CANCEL before leaving that record or that form.

If they select COMMIT, I let them out. If they select cancel, I do a Me.UnDo and rescan all controls. (Sounds ugly, but using a for ctl in me.Controls, then testing for the current color, it isn't too bad.)

Also, look up the .Dirty property, which applies to some controls on forms. It can help you figure out what has been changed.

 

[Spidey]

....

alternatively, on the AfterUpdate event of every field in a record, use a Yes/No message to the user, i.e., "Are you certain that you want to update this field?" Of course, this can be onerous. Locking and unlocking works great.

......

How is this message done? thanks!

 

[Pat Hartman]

alternatively, on the AfterUpdate event of every field in a record, use a Yes/No message to the user,

- should actually be the BeforeUpdate event.

The best place is the BeforeUpdate event of the FORM. That way you only need code in a single event.

If Me.NewRecord = False Then
    If MsgBo("Do you want to save the changes?", vbYesNo) = vbYes Then
    Else
        Cancel = True
        Me.Undo
    End If
End If

 

[Spidey]

This is a great solution if you want to warn people for the whole form, but what is the command if I just want to put a warning on a combo box? I have a combo box that selects the record to edit but I also have a combo box that selects information for a particular field. I don't want the user to get confused and think they are selecting a record when in fact they are changing a value.

 

[Pat Hartman]

The combo that selects a record isn't bound (or at least it shouldn't be) so it won't affect the form's dirty property. That means that no change to this control will cause Access to save the current record and that means that changes to an unbound control will not trigger the form's BeforeUpdate event.

Each control has its own BeforeUpdate event. You can put similar code in each control. But remember, if you put the code in the BeforeUpdate event of each field, the cancel doesn't cancel the record save, it only cancels the change to the current field and also that EVERY field would need similar code. The FORM's BeforeUpdate event is a more efficient place - plus the form level event is the ONLY place you can reliably trap null fields or fields where the contents of one depends on the contents of another.