In general, you do this in a specific context in which the user does not "see" the innards of your system. I.e. you use a switchboard/dispatcher opening form and never allow that to be closed or minimized. To do anything, your user would have to be able click a button to get where they want to go. Otherwise they could add the record directly to the table in question and you would never know they did it. That is because when a table is opened in datasheet view, you have NO CONTROL over what happens next. From a form, you have all the control you need.
NOW... having said that, the approach I used in the context I described was that any form needing the information you described would look up the Environ("Username") function to get the username by which the current user has logged in. You are in essence asking Windows to show the environmental variable that it uses to remember the login name, which is stored in a protected location. For most Windows users, it is not possible for them to change that at whim because it requires admin level privileges to reach the environment variables.
Two approaches could work. You could have a general module that you use for holding things globally across the application, and it would be the duty of the dispatcher form (in its Form_Open routine is where I put this) to store the user's name in the appropriate slot of the general module. The other approach is that each form, in ITS Form_Open routine, could store this value. As a side effect of this approach, you can do a lookup based on the username in a table of allowed users to see if the current user actually has rights to open your application, and the Form_Open routine can issue a Cancel. If you cancel the dispatcher's Form_Open event, the app doesn't open.
Then, in any form that can do a Save, you use the BeforeUpdate event to stop that save from happening UNLESS someone clicked a command button to do the save. That form would then need a Public Boolean variable to remember when your user clicked that button so that the BeforeUpdate could test for that flag, and the Save command button would have to set the flag. If you used a command-button wizard for this, there would a place where a DoCmd triggers an acSaveRecord operation. Edit the button's OnClick routine to set the flag BEFORE that DoCmd. The BeforeUpdate can issue a Cancel so if the appropriate flag isn't set, you can pop up a "Naughty, Naughty, Naughty" message box. If the flag IS set, do not issue a Cancel on the event, just clear the flag (because it needs to be a one-save-at-a-time type of flag). At that point, you know who they are (from that global "username" value) and the time of day (from Now() if nothing else), so can do whatever you need to build and store your formatted audit record.
I don't say that's the only way to do it, but that's how I approached the problem.
