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.










share|improve this question
























  • 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















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.










share|improve this question
























  • 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













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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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


















  • 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












1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted
+50










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.






share|improve this answer























  • 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













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















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

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted
+50










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.






share|improve this answer























  • 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

















up vote
1
down vote



accepted
+50










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.






share|improve this answer























  • 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















up vote
1
down vote



accepted
+50







up vote
1
down vote



accepted
+50




+50




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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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




















  • 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




















 

draft saved


draft discarded



















































 


draft saved


draft discarded














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





















































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







這個網誌中的熱門文章

Academy of Television Arts & Sciences

L'Équipe

1995 France bombings