Any field (column) that needs to have different security gets moved to a separate table. Create a one to one relationship between the two tables. Set the appropriate permissions for each piece, and the database will take care of the rest. If a user doesn't have permissions, the data will not be displayed. If they do, the will see the data.
Classic example:
HR-type database. From the HR database, a phone list is created. In the phone list, items such as SSN and pay rate should not be displayed. But for the HR manager, it should be. SSN and pay rate in a separate table, all displayed through the same query on a form. HR can then input all data, and anyone else only sees phone data stuff....
****************************
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Albert Einstein)
Robert L. Johnson III
MCSA, CNA, MCP, Network+, A+
w: robert.l.johnson.iii@citigroup.com
h: wildmage@tampabay.rr.com
The alternative is to have no one except the db admin have any permission to tables, and create queries using the "with Owner Permission" clause. This somewhat simplifies the need to seperate items in the tables. Of course it also requires that the db admin / owner write / generate the queries and provide only execute permission for them.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.