Hi Crystal,

There may be away but wouldnt it be a band aid approach to your issue?
If I'm reading you correctly, you're trying to find a way to track usage so
that now you would know who to blame. Wouldnt this mean that you would still
have problems with unwanted/bad design changes? Sure, you would now know who
did it, and you would slap his wrist or cut off his fingers so he would
never type again. But you would still end up having to correct the design
changes.

You should limit design to designers. How about coordinating the process
where:
- only designers can make design changes (pick your most qualified user or
users to be in this group)
- discussion and approval process before design changes are implemented
- there are ways to restrict regular users from getting into the design mode

This way all design changes can be maintained and controlled. Heck, there
wouldn't even be a need track usage so you can find who to blame.

HTH,
Immanuel Sibero

i agree with Immanuel; it's far better to prevent users from changing the
structure of your db at will, than to find ways to mop up the mess. first,
since your database has multiple users, it should be split into a backend
(tables only) and a frontend (all other objects), with the backend placed on
the common server, and its' tables linked to the frontend. a "master" copy
of the frontend db should be kept by the developer for subsequent
fixes/enhancements; the "production" frontend should be converted to a .mde
file and a copy of same loaded to each user's PC. the .mde file will protect
the structure of forms, reports, and VBA. to protect the structure of
queries, macros, and the tables/data, you can do various things to restrict
access to the database window; however, if you have one or more very
"Access-savvy" users, the best way to protect the whole database is by
implementing user-level security.

hth