Security Woes - how to best secure per group per table

[Kath via AccessMonster.com]

I have an MS Access db that is tracking employee info (until the organization
is ready to purchase a real HR system). Obviously, not all the information
is considered "public." So for this my design is: a front end with all the
forms, reports, etc. with links to tables. These tables exist across
multiple *.mdb files (depending upon the security needs). So basically, I am
using NTFS to secure the data. The front end shows "Tabs" and those that are
holding "secured data" are only visible to those who need it. It works - a
little complex on the understanding side as I have 4 different *.mdbs that
link to the front end.

Now the problem: due to some of the tables being housed outside of the
"common data" *.mdb file (IE: the secured *.mdb files) I cannot relate them
and referencial integrity being applied. So, deleting a record is very
problematic as it only really hits the tables within the main *.mdb
(commondata).

Anyone have any thoughts? Your input is much appreciated.
Thanks,
Kath

 

[Kath via AccessMonster.com]

BTW: I do have a key of E_NUM going across all tables, so it the matter of
having a SQL script based on current record executed when they click a cmd
button?

 

[Lynn Trapp]

Kath,
First of all, trying to store security dependent data in different tables
(in your case, in different database files) is not a good idea. It will
cause you more headaches than you can imagine. The better way is to
implement User Level Security and create Read With Owner's Permission
queries to display the data to the users who need to see it. Get a copy of
the Security FAQ, read it several times, and follow it to the letter. There
is a link to it on the Security page of my website.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html

 

[Kath via AccessMonster.com]

Thanks for the info. I guess I was nervous in implementing MS Security as I
was under the impression that the mdw file cause ill effects for other
applications. (We have many many MS Access applications which do not require
security thus would not want to impact those what so ever.) That was my lack
of use/understanding I suppose. (I did read through it and guess had trouble
in pin pointing the exact implementation to get me the results I needed.

Thanks for the response - I will read further and see if I can "register" the
information this time.

Kath,
First of all, trying to store security dependent data in different tables
(in your case, in different database files) is not a good idea. It will
cause you more headaches than you can imagine. The better way is to
implement User Level Security and create Read With Owner's Permission
queries to display the data to the users who need to see it. Get a copy of
the Security FAQ, read it several times, and follow it to the letter. There
is a link to it on the Security page of my website.

I have an MS Access db that is tracking employee info (until the
organization

[quoted text clipped - 22 lines]

Thanks,
Kath

 

[Kath via AccessMonster.com]

Also - one more thing - we delivery Applications through a Citrix environment
- which I believe had a part to do with my conclusions. As I said....I will
re-read and see if it was just me - which I am not doubting at this point.

Thanks for the info. I guess I was nervous in implementing MS Security as I
was under the impression that the mdw file cause ill effects for other
applications. (We have many many MS Access applications which do not require
security thus would not want to impact those what so ever.) That was my lack
of use/understanding I suppose. (I did read through it and guess had trouble
in pin pointing the exact implementation to get me the results I needed.

Thanks for the response - I will read further and see if I can "register" the
information this time.

Kath,
First of all, trying to store security dependent data in different tables

[quoted text clipped - 10 lines]

 

[Kath via AccessMonster.com]

Now I remember why I did not want to secure it this way (using MS Access
Security) I do not want to have everyone enter a logon name and password.
(The entire organization - approx 80+ will use this system for retrieval of
employee data.) I just want to assure that only the HR and Supervisors can
see the 'sensitive or private' information.

Any ideas?

Thanks for the info. I guess I was nervous in implementing MS Security as I
was under the impression that the mdw file cause ill effects for other
applications. (We have many many MS Access applications which do not require
security thus would not want to impact those what so ever.) That was my lack
of use/understanding I suppose. (I did read through it and guess had trouble
in pin pointing the exact implementation to get me the results I needed.

Thanks for the response - I will read further and see if I can "register" the
information this time.

Kath,
First of all, trying to store security dependent data in different tables

[quoted text clipped - 10 lines]

 

[Joan Wild]

Now I remember why I did not want to secure it this way (using MS Access
Security) I do not want to have everyone enter a logon name and password.
(The entire organization - approx 80+ will use this system for retrieval
of
employee data.) I just want to assure that only the HR and Supervisors
can
see the 'sensitive or private' information.

You can secure it so that they don't have to login. For the general users,
assign appropriate permissions to the Users Group. When they use their
default system.mdw, they'll be restricted by the permissions you've set for
the Users Group.

For the HR and Supervisors, they will have to login. You'd provide them
with the secure mdw.
See http://www.jmwild.com/SecureNoLogin.htm