Access: 2 roles on the same DB with different roles
up vote
-1
down vote
favorite
I have an Access Database on the SharePoint and two user's roles that have to work on it:
Role1 is given to a single user. He can manage all the forms of the DB with the possibility to change all the tables. These forms will require many future releases.
Role2 is given to many users. They can manage only one form that is effective only on a single table of the DB. He doesn't (and mustn't) need to see/manage the others forms/tables (they are a lot). The form used for this role will not require future releases.
What it the best practice to manage this? I thought about the following 2 solutions but probably there is a third one that is better.
Solution #1
Having 2 different Access files linked to the same DB: one with all the forms (that I give to Role1) and one with only one form (that I give to Role2).
Solution #2
Having a single Access file that I give to both the users. Role1 has read/write access to all forms. Role2 can see only a specific form and has no read/write access to other forms.
ms-access
add a comment |
up vote
-1
down vote
favorite
I have an Access Database on the SharePoint and two user's roles that have to work on it:
Role1 is given to a single user. He can manage all the forms of the DB with the possibility to change all the tables. These forms will require many future releases.
Role2 is given to many users. They can manage only one form that is effective only on a single table of the DB. He doesn't (and mustn't) need to see/manage the others forms/tables (they are a lot). The form used for this role will not require future releases.
What it the best practice to manage this? I thought about the following 2 solutions but probably there is a third one that is better.
Solution #1
Having 2 different Access files linked to the same DB: one with all the forms (that I give to Role1) and one with only one form (that I give to Role2).
Solution #2
Having a single Access file that I give to both the users. Role1 has read/write access to all forms. Role2 can see only a specific form and has no read/write access to other forms.
ms-access
I would choose option 2.
– June7
Nov 8 at 0:05
@June7 thanks. I have detailed more the issue (Role1 has high-frequency change forms, while Role2 has a single form that will never change). Will this change your answer?
– Stefano
Nov 8 at 8:52
IMHO, If you have read write access to an Access Database (AKA not (accde, accdr)) then any security you provide is useless. Because the user can easily bypass or remove the restriction.
– krish KM
Nov 9 at 14:26
Agree that security with Access is minimal. I would choose to manage 1 frontend and use code to determine which form is presented to user. But use two files if you prefer. There is no 'right' answer, only suggestion and opinion.
– June7
Nov 11 at 2:34
add a comment |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
I have an Access Database on the SharePoint and two user's roles that have to work on it:
Role1 is given to a single user. He can manage all the forms of the DB with the possibility to change all the tables. These forms will require many future releases.
Role2 is given to many users. They can manage only one form that is effective only on a single table of the DB. He doesn't (and mustn't) need to see/manage the others forms/tables (they are a lot). The form used for this role will not require future releases.
What it the best practice to manage this? I thought about the following 2 solutions but probably there is a third one that is better.
Solution #1
Having 2 different Access files linked to the same DB: one with all the forms (that I give to Role1) and one with only one form (that I give to Role2).
Solution #2
Having a single Access file that I give to both the users. Role1 has read/write access to all forms. Role2 can see only a specific form and has no read/write access to other forms.
ms-access
I have an Access Database on the SharePoint and two user's roles that have to work on it:
Role1 is given to a single user. He can manage all the forms of the DB with the possibility to change all the tables. These forms will require many future releases.
Role2 is given to many users. They can manage only one form that is effective only on a single table of the DB. He doesn't (and mustn't) need to see/manage the others forms/tables (they are a lot). The form used for this role will not require future releases.
What it the best practice to manage this? I thought about the following 2 solutions but probably there is a third one that is better.
Solution #1
Having 2 different Access files linked to the same DB: one with all the forms (that I give to Role1) and one with only one form (that I give to Role2).
Solution #2
Having a single Access file that I give to both the users. Role1 has read/write access to all forms. Role2 can see only a specific form and has no read/write access to other forms.
ms-access
ms-access
edited Nov 8 at 8:50
asked Nov 7 at 18:49
Stefano
11118
11118
I would choose option 2.
– June7
Nov 8 at 0:05
@June7 thanks. I have detailed more the issue (Role1 has high-frequency change forms, while Role2 has a single form that will never change). Will this change your answer?
– Stefano
Nov 8 at 8:52
IMHO, If you have read write access to an Access Database (AKA not (accde, accdr)) then any security you provide is useless. Because the user can easily bypass or remove the restriction.
– krish KM
Nov 9 at 14:26
Agree that security with Access is minimal. I would choose to manage 1 frontend and use code to determine which form is presented to user. But use two files if you prefer. There is no 'right' answer, only suggestion and opinion.
– June7
Nov 11 at 2:34
add a comment |
I would choose option 2.
– June7
Nov 8 at 0:05
@June7 thanks. I have detailed more the issue (Role1 has high-frequency change forms, while Role2 has a single form that will never change). Will this change your answer?
– Stefano
Nov 8 at 8:52
IMHO, If you have read write access to an Access Database (AKA not (accde, accdr)) then any security you provide is useless. Because the user can easily bypass or remove the restriction.
– krish KM
Nov 9 at 14:26
Agree that security with Access is minimal. I would choose to manage 1 frontend and use code to determine which form is presented to user. But use two files if you prefer. There is no 'right' answer, only suggestion and opinion.
– June7
Nov 11 at 2:34
I would choose option 2.
– June7
Nov 8 at 0:05
I would choose option 2.
– June7
Nov 8 at 0:05
@June7 thanks. I have detailed more the issue (Role1 has high-frequency change forms, while Role2 has a single form that will never change). Will this change your answer?
– Stefano
Nov 8 at 8:52
@June7 thanks. I have detailed more the issue (Role1 has high-frequency change forms, while Role2 has a single form that will never change). Will this change your answer?
– Stefano
Nov 8 at 8:52
IMHO, If you have read write access to an Access Database (AKA not (accde, accdr)) then any security you provide is useless. Because the user can easily bypass or remove the restriction.
– krish KM
Nov 9 at 14:26
IMHO, If you have read write access to an Access Database (AKA not (accde, accdr)) then any security you provide is useless. Because the user can easily bypass or remove the restriction.
– krish KM
Nov 9 at 14:26
Agree that security with Access is minimal. I would choose to manage 1 frontend and use code to determine which form is presented to user. But use two files if you prefer. There is no 'right' answer, only suggestion and opinion.
– June7
Nov 11 at 2:34
Agree that security with Access is minimal. I would choose to manage 1 frontend and use code to determine which form is presented to user. But use two files if you prefer. There is no 'right' answer, only suggestion and opinion.
– June7
Nov 11 at 2:34
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
I would recommend solution #2 otherwise if you change the logic in the front end you have to change it always twice and this is really annoying. Also, if you forget to change both versions and you had a huge change in the logic, you have people working with the old version and people working with the new version.
What I normally do is the following. I have a table tblDeveloperAccess with the ID of your Role1. At the start of the first form load event I have the following code:
Dim db As Database
Dim rs As Recordset
Set db = CurrentDb
Set rs = db.OpenRecordset("tbDeveloperAccess", dbOpenSnapshot)
rs.FindFirst "ID = '" & Environ("USERNAME") & "'"
If rs.NoMatch Then
DoCmd.NavigateTo "acNavigationCategoryObjectType", "acNavigationGroupTables"
DoCmd.SelectObject acForm, vbNullString, True
DoCmd.RunCommand acCmdWindowHide
DoCmd.ShowToolbar "Ribbon", acToolbarNo
End If
Basically I am hiding the ribbon and the object navigation. You can go even further and disable the context menu and the "Shift + DblClick"-Trick (on your database file). And of course I disable the possibilty on the start form to get into the design view.
Any approach relying on the user being unable to view or alter code of an uncompiled, unencrypted database is fundamentally flawed and offers very little security. You can toggle the Shift + Double click option by directly editing the database through DAO and another VBA program, disable VBA altogether, etc.
– Erik von Asmuth
Nov 13 at 11:43
Yes thats true. For more security more effort would be needed.
– Strawberryshrub
Nov 13 at 12:00
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
I would recommend solution #2 otherwise if you change the logic in the front end you have to change it always twice and this is really annoying. Also, if you forget to change both versions and you had a huge change in the logic, you have people working with the old version and people working with the new version.
What I normally do is the following. I have a table tblDeveloperAccess with the ID of your Role1. At the start of the first form load event I have the following code:
Dim db As Database
Dim rs As Recordset
Set db = CurrentDb
Set rs = db.OpenRecordset("tbDeveloperAccess", dbOpenSnapshot)
rs.FindFirst "ID = '" & Environ("USERNAME") & "'"
If rs.NoMatch Then
DoCmd.NavigateTo "acNavigationCategoryObjectType", "acNavigationGroupTables"
DoCmd.SelectObject acForm, vbNullString, True
DoCmd.RunCommand acCmdWindowHide
DoCmd.ShowToolbar "Ribbon", acToolbarNo
End If
Basically I am hiding the ribbon and the object navigation. You can go even further and disable the context menu and the "Shift + DblClick"-Trick (on your database file). And of course I disable the possibilty on the start form to get into the design view.
Any approach relying on the user being unable to view or alter code of an uncompiled, unencrypted database is fundamentally flawed and offers very little security. You can toggle the Shift + Double click option by directly editing the database through DAO and another VBA program, disable VBA altogether, etc.
– Erik von Asmuth
Nov 13 at 11:43
Yes thats true. For more security more effort would be needed.
– Strawberryshrub
Nov 13 at 12:00
add a comment |
up vote
1
down vote
accepted
I would recommend solution #2 otherwise if you change the logic in the front end you have to change it always twice and this is really annoying. Also, if you forget to change both versions and you had a huge change in the logic, you have people working with the old version and people working with the new version.
What I normally do is the following. I have a table tblDeveloperAccess with the ID of your Role1. At the start of the first form load event I have the following code:
Dim db As Database
Dim rs As Recordset
Set db = CurrentDb
Set rs = db.OpenRecordset("tbDeveloperAccess", dbOpenSnapshot)
rs.FindFirst "ID = '" & Environ("USERNAME") & "'"
If rs.NoMatch Then
DoCmd.NavigateTo "acNavigationCategoryObjectType", "acNavigationGroupTables"
DoCmd.SelectObject acForm, vbNullString, True
DoCmd.RunCommand acCmdWindowHide
DoCmd.ShowToolbar "Ribbon", acToolbarNo
End If
Basically I am hiding the ribbon and the object navigation. You can go even further and disable the context menu and the "Shift + DblClick"-Trick (on your database file). And of course I disable the possibilty on the start form to get into the design view.
Any approach relying on the user being unable to view or alter code of an uncompiled, unencrypted database is fundamentally flawed and offers very little security. You can toggle the Shift + Double click option by directly editing the database through DAO and another VBA program, disable VBA altogether, etc.
– Erik von Asmuth
Nov 13 at 11:43
Yes thats true. For more security more effort would be needed.
– Strawberryshrub
Nov 13 at 12:00
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
I would recommend solution #2 otherwise if you change the logic in the front end you have to change it always twice and this is really annoying. Also, if you forget to change both versions and you had a huge change in the logic, you have people working with the old version and people working with the new version.
What I normally do is the following. I have a table tblDeveloperAccess with the ID of your Role1. At the start of the first form load event I have the following code:
Dim db As Database
Dim rs As Recordset
Set db = CurrentDb
Set rs = db.OpenRecordset("tbDeveloperAccess", dbOpenSnapshot)
rs.FindFirst "ID = '" & Environ("USERNAME") & "'"
If rs.NoMatch Then
DoCmd.NavigateTo "acNavigationCategoryObjectType", "acNavigationGroupTables"
DoCmd.SelectObject acForm, vbNullString, True
DoCmd.RunCommand acCmdWindowHide
DoCmd.ShowToolbar "Ribbon", acToolbarNo
End If
Basically I am hiding the ribbon and the object navigation. You can go even further and disable the context menu and the "Shift + DblClick"-Trick (on your database file). And of course I disable the possibilty on the start form to get into the design view.
I would recommend solution #2 otherwise if you change the logic in the front end you have to change it always twice and this is really annoying. Also, if you forget to change both versions and you had a huge change in the logic, you have people working with the old version and people working with the new version.
What I normally do is the following. I have a table tblDeveloperAccess with the ID of your Role1. At the start of the first form load event I have the following code:
Dim db As Database
Dim rs As Recordset
Set db = CurrentDb
Set rs = db.OpenRecordset("tbDeveloperAccess", dbOpenSnapshot)
rs.FindFirst "ID = '" & Environ("USERNAME") & "'"
If rs.NoMatch Then
DoCmd.NavigateTo "acNavigationCategoryObjectType", "acNavigationGroupTables"
DoCmd.SelectObject acForm, vbNullString, True
DoCmd.RunCommand acCmdWindowHide
DoCmd.ShowToolbar "Ribbon", acToolbarNo
End If
Basically I am hiding the ribbon and the object navigation. You can go even further and disable the context menu and the "Shift + DblClick"-Trick (on your database file). And of course I disable the possibilty on the start form to get into the design view.
edited Nov 18 at 23:48
June7
3,83441126
3,83441126
answered Nov 13 at 9:56
Strawberryshrub
8431215
8431215
Any approach relying on the user being unable to view or alter code of an uncompiled, unencrypted database is fundamentally flawed and offers very little security. You can toggle the Shift + Double click option by directly editing the database through DAO and another VBA program, disable VBA altogether, etc.
– Erik von Asmuth
Nov 13 at 11:43
Yes thats true. For more security more effort would be needed.
– Strawberryshrub
Nov 13 at 12:00
add a comment |
Any approach relying on the user being unable to view or alter code of an uncompiled, unencrypted database is fundamentally flawed and offers very little security. You can toggle the Shift + Double click option by directly editing the database through DAO and another VBA program, disable VBA altogether, etc.
– Erik von Asmuth
Nov 13 at 11:43
Yes thats true. For more security more effort would be needed.
– Strawberryshrub
Nov 13 at 12:00
Any approach relying on the user being unable to view or alter code of an uncompiled, unencrypted database is fundamentally flawed and offers very little security. You can toggle the Shift + Double click option by directly editing the database through DAO and another VBA program, disable VBA altogether, etc.
– Erik von Asmuth
Nov 13 at 11:43
Any approach relying on the user being unable to view or alter code of an uncompiled, unencrypted database is fundamentally flawed and offers very little security. You can toggle the Shift + Double click option by directly editing the database through DAO and another VBA program, disable VBA altogether, etc.
– Erik von Asmuth
Nov 13 at 11:43
Yes thats true. For more security more effort would be needed.
– Strawberryshrub
Nov 13 at 12:00
Yes thats true. For more security more effort would be needed.
– Strawberryshrub
Nov 13 at 12:00
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53195905%2faccess-2-roles-on-the-same-db-with-different-roles%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I would choose option 2.
– June7
Nov 8 at 0:05
@June7 thanks. I have detailed more the issue (Role1 has high-frequency change forms, while Role2 has a single form that will never change). Will this change your answer?
– Stefano
Nov 8 at 8:52
IMHO, If you have read write access to an Access Database (AKA not (accde, accdr)) then any security you provide is useless. Because the user can easily bypass or remove the restriction.
– krish KM
Nov 9 at 14:26
Agree that security with Access is minimal. I would choose to manage 1 frontend and use code to determine which form is presented to user. But use two files if you prefer. There is no 'right' answer, only suggestion and opinion.
– June7
Nov 11 at 2:34