Irene,

There are ways of traking this, but you basically end up having a database
to track your database!  You really need to ask yourself if it is worth
doing.  If you implemenet security to ensure only the appropriate users can
make changes..., do you really need to go down the path of logging every
action that occurs?

But the short answer is yes it can be done.  Using commands such as
currentuser() you can identify the user that made a change.  In conjunction
with your form events (after_update, etc.) you can create a generic function
to write the username, date/time, form name, .... into an audit table of
sorts.

Take a look at http://allenbrowne.com/AppAudit.html for a good starting
point.  From there you can customize it to suit your needs.

Personnally, I have never needed to go down to that level of user tracking.

Irene,  

There is a technique in the Access Cookbook by Ken Getz, P. Litwin and A
Baron that may help you.  

It calls for adding four fields to your audit table: DateCreated;
UserCreated; DateModified; and, UserModified.  The date fields are set to
Now().  

You then add these fields to your forms.  They can invisible if you need to
audit usage candestinely.  

You then set the Enabled property of the controls to  No  and Locked
property to  Yes.  Next you create a BeforeInsert event with one line:  
Me!UserCreated = CurrentUser().  

Then create a BeforeUpdate event with the first statement as Me!DateModified
= Now().  Follow that line with Me!UserModified = CurrentUser().   The
CurrentUser function needs to have user-level security implemented (this
explains why it didn't  work for me this week in Access 2007).

The Cookbook has some very useful explanations for coding Access.  I am
waiting with checkbook in hand for the Access 2007 edition.  

HTH.

LDN

Jan Baird is out of the country until September 20.   Every effort will be
made to respond to messages, but please be patient.