Hello Cindy,
I thought I'd supply some "theory" to help you to understand how to solve 
your problem with the EDITED field.
There is a certain sequence to the events triggered for a form and it's 
controls .
I'll only discuss those events here that are related to what you want to do.
Controls:
The OnChange event of a control is fired as soon as you change the content of 
the control, e.g. type in a new character or delete/change one. It is fired 
EACH TIME you do that, so if you enter somebody's last name for example, the 
event will be fired for every character you enter.
The BeforeUpdate event of a control is fired when you by whatever way leave 
the control or move the focus elsewhere after you made changes to it's 
contents. This event is IMHO mainly meant to give you a chance to check the 
entry for validity. The event procedure has a Cancel parameter that you can 
set to True if the entry doesn't please you or violates a validity rule.
If you set this paraneter, Access will not permit "leaving" the control until 
your check routine does NOT set the Cancel parameter to True, that is, the 
routine is satisfied with the current contents.
The AfterUpdate event of a control is fired after all validation implemented 
for that control has taken place and the new contents are accepted as valid. 
You may implement other operations here that may become necessary when a 
control takes a certain value.
Forms:
The BeforeUpdate event of a form is fired when you tell Access to save the 
record, e.g. by moving to another record, clicking the record selector on the 
form or use a menu command or shortcut key, but BEFORE the form's contents 
are written to the underlying table record(s) in the database. This gives you 
a chance to perform per record validation and the like. The event procedue 
has a Cancel parameter again, so you can keep an invalid RECORD from being 
saved to the table. The rest works as explained for a control's BeforeUpdate 
event.
The AfterUpdate event of a form is fired when all validation succeeded and 
the RECORD HAS BEEN SAVED to the database. See above for further 
lanations.
Now for your problem:
If you want to trace changes to the entire record regardless of the fields 
that were changed, the way to do it is to create a BeforeUpdate procedure for 
the form, looking about like this:
Access 2:
*****************************************
Sub Form_BeforeUpdate(Cancel As Integer)
Me![Edited] = Now
End Sub
*****************************************
'
Access 7:
*****************************************
Private Sub Form_BeforeUpdate(Cancel As Integer)
Me![Edited] = Now
End Sub
*****************************************
To clarify the code above:
The "Me" in the code refers to the form the piece of code is associated with, 
so Me!Edited refers to the control "Edited" on the current form.
Sidestep:
The [] characters may be left out if you refer to a control with an 
alphanumeric name not including spacesand the like, but they don't hurt if 
they are there.
Assign >Now< to the Edited control if you want the exact date and time of the 
change stored in the field.
Assign >Date< if you are not interested in the time of the change and just 
want to store the date part.
Using the syntax "Me![Edited]" instead of just "[Edited]" makes that 
reference as unambiguous as possible and the code more readable.
Why not use control events?
This adds unnecessary processing if you only want to know when something in 
the record changed, not which individual control/field was changed. You also 
would have to create event procs for every control on the form, not just one 
as when using the form events.
Why not use the AfterUpdate event of the form?
There is a serious drawback on this: it doesn't work :-)
Firstly, the record has already been saved at this point and the change of 
the value happens AFTER the record was written, so it is not reflected in the 
table!
Secondly, when yu change the value, the record becomes "dirty" again, meaning 
the latest changes are not saved to disk. This produces an endless loop, 
because each time you save the record, the Edited control is updated again 
and you have to save again and the control is updated again and...
I hope you may gain some "insights" out of this little essay that may help 
you understanding how Access works in this particular area :-)))
CUl8R
  Kai
* Origin: I'm not in originate mode :-( (2:2433/1625.2)
--- FLAME v1.1/b
---------------