|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
How to split Front end/Back endIve read that what i need to do to my DB is split the front end and back end.
But no one really explains HOW to do it. I hope it doesnt have to be done before you design the database as i already have A LOT of time and energy into this one. I know the "back end" has to be stored on the shared drive and the front end is copied onto each computer but how do you go about actually splitting the database? Nobody explains how to do it because they use the Database Splitter Wizard to
do it for them. Tools > Database utilities > Database splitter. But use the wizard *only* if your db file isn't secured. If it is, please post back and I'll give you instructions on how to split it and keep both ends secured. Chris Gary wrote: >Ive read that what i need to do to my DB is split the front end and back end. > But no one really explains HOW to do it. I hope it doesnt have to be done >before you design the database as i already have A LOT of time and energy >into this one. I know the "back end" has to be stored on the shared drive >and the front end is copied onto each computer but how do you go about >actually splitting the database? -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200902/1 It isnt secured yet, but probably will be before it is finished. But seeing
as users wont have access to the tables is there a need for it to be secured? It is a simple database but it is FDA required so it MUST be stable. I dont want complete open access for most people. I want the ability to create a new entry to be open, but the ability to modify current records secured to a set list of people. Show quoteHide quote "Chris O'C via AccessMonster.com" wrote: > Nobody explains how to do it because they use the Database Splitter Wizard to > do it for them. Tools > Database utilities > Database splitter. But use the > wizard *only* if your db file isn't secured. If it is, please post back and > I'll give you instructions on how to split it and keep both ends secured. > > Chris > > > Gary wrote: > >Ive read that what i need to do to my DB is split the front end and back end. > > But no one really explains HOW to do it. I hope it doesnt have to be done > >before you design the database as i already have A LOT of time and energy > >into this one. I know the "back end" has to be stored on the shared drive > >and the front end is copied onto each computer but how do you go about > >actually splitting the database? > > -- > Message posted via AccessMonster.com > http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200902/1 > > "Gary" <G***@discussions.microsoft.com> wrote in message If it's not secured then how are you denying your users access to the news:22A88D81-D62B-4E76-8E25-05DC6A7E25F8@microsoft.com... > But seeing > as users wont have access to the tables is there a need for it to be > secured? tables? If you've set start-up options to hide the db window then a savvy user can hold down the shift key on opening or press F11 to unhide it. Keith. www.keithwilby.co.uk Right now this is in the complete design phase. No one is using it right
now. And I know the shift key method, but as I need a group of people to have access rights to previously entered records to modify and update them to be the only people who have that ability, and “all users†to have the ability to create a new record…. I was just trying to get the multi-users aspect worked out and all of the little kinks/quarks that the database has before I go further with the security aspect of it. I did test the splitting of the database and it worked perfectly. Thank you very much. Show quoteHide quote "Keith Wilby" wrote: > "Gary" <G***@discussions.microsoft.com> wrote in message > news:22A88D81-D62B-4E76-8E25-05DC6A7E25F8@microsoft.com... > > But seeing > > as users wont have access to the tables is there a need for it to be > > secured? > > If it's not secured then how are you denying your users access to the > tables? If you've set start-up options to hide the db window then a savvy > user can hold down the shift key on opening or press F11 to unhide it. > > Keith. > www.keithwilby.co.uk > > "Gary" <G***@discussions.microsoft.com> wrote in message OK post back when you're ready for security. It's a pretty complex topic. news:32735E25-1D84-40C4-812B-4CA3676E240D@microsoft.com... > Right now this is in the complete design phase. No one is using it right > now. And I know the shift key method, but as I need a group of people to > have access rights to previously entered records to modify and update them > to > be the only people who have that ability, and “all users†to have the > ability > to create a new record…. I was just trying to get the multi-users aspect > worked out and all of the little kinks/quarks that the database has before > I > go further with the security aspect of it. My web site has a couple of links to get you started. > Splitting's pretty straightforward, security can bite you if you're not > I did test the splitting of the database and it worked perfectly. > Thank you very much. > careful! :) Keith. www.keithwilby.co.uk Anybody with access to the db file has access to the tables inside it. You
can add user level security to restrict viewing the tables, but it's not real security. If you need security for social security numbers, salaries, employee addresses and the like, store the data in SQL Server and take the steps to make that secure. Chris Gary wrote: >But seeing >as users wont have access to the tables is there a need for it to be secured? Its not a matter of viewing the data, this data is fairly generic, but its a
matter of changing what has been entered. I need any user to be able to create but only a few to be able to edit. Show quoteHide quote "Chris O'C via AccessMonster.com" wrote: > Anybody with access to the db file has access to the tables inside it. You > can add user level security to restrict viewing the tables, but it's not real > security. If you need security for social security numbers, salaries, > employee addresses and the like, store the data in SQL Server and take the > steps to make that secure. > > Chris > > > Gary wrote: > >But seeing > >as users wont have access to the tables is there a need for it to be secured? > > -- > Message posted via http://www.accessmonster.com > > With user level security you can assign permissions to restrict some users to
inserting records, others to updating records, still others to deleting records, and some users only get to read the records. Or you can use a combination of these restrictions. But these are only restrictions, not security. Anybody with the know-how can bypass them unless you use a secure db, like SQL Server to assign permissions. Chris Gary wrote: >Its not a matter of viewing the data, this data is fairly generic, but its a >matter of changing what has been entered. I need any user to be able to >create but only a few to be able to edit. -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200902/1 I appreciate everyone's help. I doubt that anyone here has the "know how" or
the desire to actually tamper with the info. I just wanted it safer in case of accidents. Show quoteHide quote "Chris O'C via AccessMonster.com" wrote: > With user level security you can assign permissions to restrict some users to > inserting records, others to updating records, still others to deleting > records, and some users only get to read the records. Or you can use a > combination of these restrictions. > > But these are only restrictions, not security. Anybody with the know-how can > bypass them unless you use a secure db, like SQL Server to assign permissions. > > > Chris > > > Gary wrote: > >Its not a matter of viewing the data, this data is fairly generic, but its a > >matter of changing what has been entered. I need any user to be able to > >create but only a few to be able to edit. > > -- > Message posted via AccessMonster.com > http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200902/1 > > "Gary" <G***@discussions.microsoft.com> wrote in message Then ULS will serve your purpose mightily. To crack security you'd need to news:508F5B30-4F22-4BE9-89A4-30B5573A037D@microsoft.com... >I appreciate everyone's help. I doubt that anyone here has the "know how" >or > the desire to actually tamper with the info. I just wanted it safer in > case > of accidents. > be a hacker. In my organisation that would be a sacking offence so ULS is perfectly adequate. I suspect that ULS is used in such scenarios all over the place. Keith. www.keithwilby.co.uk  
Other interesting topics
type mismatch and allowbypasskey
.mdb file is read only... Multi-User input and db protection HELP! Shortcut needs to work in a Domain instead of a workgroup Access cannot open file on stand alone computer I cannot open a DB created by another user on my PC. help understanding mdw files! AllowBypassKey and Type Mismatch Error How to hide table using User-Level Security |
|||||||||||||||||||||||
