>Could you post a basic idea of how you implemented this audit trail information? I have the need to do similar work in my own system.

There are two basic ways: 1) use a third-party product (what the heck's the name of that vfp audit tool?, someone help me here..), or 2) build your own. I built my own, with a simple audit table that has columns for:

Table Name
PK
Field Edited
Old value (memo)
New Value (memo)
User Name
Date/Time

and any other relevant fields, some possibly hidden from user, like FKs. The values have to be memos since some of the edited fields are memos, too. All non-char types are converted into char values and written to the value memos in this table. This table is table-buffered during user edits (an Insert is done for each edit), and every time a normal user Save is made, this table is Tableupdated too.

The audit table is available to users in a grid with search/sort/print options, and older edits may be archived periodically to keep it from growing too large.
The old edits are retained permanently, anyway, so an admin can access them if needed from long ago. Only one table is needed, though.

Entire Deleted or Added records are treated differently, they are written to separate backup-type tables with codes and comment fields to indicate who/when/why they were done. They are also shown in a grid with similar search/sort/print options, and users can recall their own deleted records (add them back to primary DB) within a timeframe, or view other users' changes. These changes are permanently kept in the same way as the edit-audits, but may require more than one table since each editable DB table may require a separate full-record audit trail. I only use these on a few really critical tables, however.

I also keep long-term backup tapes, of course, but I discovered long-ago that it's virtually preposterous to try to hunt down data changes with a big box of old DAT tapes :-)