Password setup showing hisotry of records changed

[Guest]

I need to set up security and have never done this before. I am an
intermediate to advanced level user whose new boss wants to have a form have
permissions for the following (I am giving ideas at the same time):

1.)The form will only let the user change the record (probably based on the
autonumber and the Logged by field) that he or she entered.
2)The form will have a history table (possibly as a subtable named Changes
History for each record, when that record was changed, the date and time,
etc.)

Once you set up the security for each user, when they log on to the database
and go that record to change it, will it stamp their user ID in the Changes
History subtable simultaneously not letting them change a record that they
didn't create?

 

[Joan Wild]

Allen Browne has an audit trail sample on his site you can use:
www.allenbrowne.com/AppAudit.html

Do users need to see other's records? If they don't then you can base your form on a query that uses the CurrentUser() function as a criteria on the 'user ID' field. If they do need to see other's records (but not edit them), then you can write code in the Current event of the form to check if the user ID = CurrentUser() and change the AllowEdits/AllowDeletions properties of the form.

 

[Guest]

Ok that makes sense. But could you help me with the code? Does this involve
setting up the security as well? I set up security with the security wizard,
but now it won't let me do anything even though I set myself up as an Admin.
Guess I'll have to import all the objects to a new database sicne that's the
only way to get around this problem.

 

[Guest]

One more thing...users do need to see other's records but not edit them, just
their own. Would that be based from a drop down box that shows all the users
(this drop down box comes from an Employees table that I concatenated to show
first and last name).

 

[Joan Wild]

If you don't want to implement user level security, I believe Allen's example uses the Windows username - you can go that route instead. I believe that his example has a link to the code to get the Windows username instead.
Re:
One more thing...users do need to see other's records but not edit them, just
their own. Would that be based from a drop down box that shows all the users
(this drop down box comes from an Employees table that I concatenated to show
first and last name).

No you wouldn't need to do that. You can use the same function that Allen refers to get the Windows username and change the form's properties based on that. This way you don't need to have the user select their 'name' from a list - what would stop them from choosing a different name than themselves?