In a secured Database; basic access rights to Objects like Tables, Forms, Queries and Reports are defined for specific Workgroups/Users as a one time exercise. This takes effect automatically when a User belongs to a particular Workgroup accesses the Database Objects.
For example: Assume that the Employees Table is set with only Read Data permission for GroupA Workgroup. When a User belongs to GroupA opens the Employees Form with the Employees Table as Record Source or opens the Table directly, he cannot execute Update/Insert/Delete Data operations on the Table.
But, if we want to make this scenario little more flexible like allowing to Update data then this can be enabled on the User and Group Permissions Control under Security of Tools Menu.
Image may be NSFW.
Clik here to view.
In this case all Users belongs to GroupA Workgroup can Edit and Update all Data Fields of the Employees Table. Normally, Users are never allowed to open Tables directly but through Data Entry/Edit/Display Forms so that the Developer have more control on the Users.
When we assign Update Data permission all data fields can be modified/updated by Users. But, if we want to prevent the Users from making changes to certain fields; it cannot be done through the normal security implementation method explained above.
This level of security can be implement only through Visual Basic Programs. This method can be implemented in the following way:
- When the Employees Form is open by the User for normal operations we can get the User Name with the use of CurrentUser() Function.
- Next step is to check whether this User belongs to the GroupA Workgroup or not.
- If so then lock the BirthDate and HireDate fields so that the current user is prevented from making changes to these two fields.
We need two programs to try out this method:
- A Function to check and confirm whether the User Name passed to it belongs to a particular Workgroup, if so send a positive signal back to the calling program.
- If the User is identified as a member of the GroupA Workgroup then the BirthDate and HireDate data fields are locked on the Form through the Form_Load() Event Procedure so that the current user cannot edit the contents of these fields.
- If the User belongs to some other Workgroup then the above fields are unlocked and allowed to edit/update.
To try this out:
- Import the Employees Table and Employees Form from the sample database C:\Program Files\Microsoft Office\Office11\Samples\Northwind.mdb.
- Open and existing Standard VBA Module or create a new one.
- Copy and paste the following Visual Basic Code into the Module and save it:
Public Function UserGroupCheck(ByVal strGroupName As String, ByVal strUserName As String) As Boolean Dim WrkSpc As Workspace, Usr As User On Error GoTo UserGroupCheck_Err Set WrkSpc = DBEngine.Workspaces(0) For Each Usr In WrkSpc.Groups(strGroupName).Users If Usr.Name = strUserName Then UserGroupCheck = True Exit For Else UserGroupCheck = False End If Next UserGroupCheck_Exit: Exit Function UserGroupCheck_Err: MsgBox Err.Description, , "UserGroupCheck_Err" Resume UserGroupCheck_Exit End Function
- Open the Employees Form in Design View.
- Display the Form’s VBA Module (View – -> Code).
- Copy and paste the following Code into the VBA Module and save the Form:
Private Sub Form_Load() Dim strUser As String, strGroup As String, boolFlag As Boolean strUser = CurrentUser strGroup = "GroupA" 'replace the GroupA value with your own test Group Name boolFlag = UserGroupCheck(strGroup, strUser) If boolFlag Then Me.BirthDate.Locked = True Me.HireDate.Locked = True Else Me.BirthDate.Locked = False Me.HireDate.Locked = False End If End Sub
- Open the Form in normal View.
- Try to change the existing values in the BirthDate and HireDate Fields.
If the Current User name belongs to the Workgroup name you have assigned to the strGroup Variable then the Birthdate and HireDate fields will be in locked state.
Tip: Even if your database is not implemented with Microsoft Access Security you can test these programs. Assign the value Admins to the strGroup variable in the above Subroutine. By default you will be logged in as Admin User, as a member of the Admins Workgroup. This will lock both the above test fields from editing when the Employees Form is open.