Daniel, while that ideal is noble, I don't see that it will be practical.

Firstly, Access (JET) does not give logs, and does not expose triggers. If
all inserts, deletes, and edits are made through forms, and there are no
cascading relations or replication syncs, it is possible to use the events
of the form to create a transaction log. The deletions are the most awkward,
as it is possible to delete several records at once. If you are interested
in following that through, see:
   Audit Trail - Log changes at the record level
at:
   http://allenbrowne.com/AppAudit.html

The second stage would be to write code to rollback to a particular point in
the past. That's doaable, but messy. You might find at this stage that you
are better of using SQL Sever tables than JET, since that gives you full
transaction logging and rollbacks without the need to code it and rely on
the form events.

But you want to do selective rollback. In my way of thinking that's
logically inconsistent. Example:
Car A is deleted.
It's a Sports car.
All sports cars now have a 10% rise in price.
Car A is restored.
Did you also need to give it a price rise?

In other words, is there an entire queue of things that could have affected
car A while it was gone, that need to be applied how it is back again? How
do you manage that queue? Deciding which ones are relevant, and in which
order is not simple. Deciding how to perform multiple interacting and
potentially conflicting undos in any order is, I think, impossible.