Microsoft provides a method to grant permisisons to individual columns within a table. Row-level security, however,...
is implemented using a "view", a stored proc, or SQL function. The method I most commonly see is using a SQL view--it's a lot easier than trying to manage column permissions. Instead, you grant SQL permissions to the view, not the underlying table. With creative use of a WHERE clause, you should only need one "view" for every type of database access. For example, a customer service rep viewing his/her trouble tickets can be accomplished by creating a view that filters the TroubleTicket database for tickets WHERE AgentName = SUSER_NAME(), a built-in SQL function that returns the currently logged-in username. This ensures that all actions taken using the view will only affect tickets for that agent. Deny permissions to all the tables and only grant your users permissions to the views.
Step-by-Step Guide: How to patch SQL Server
This two-part series on SQL Server patch deployment will help you track down those pesky servers then walk you through patch deployment and the various options available to you.
Learn how to put row-level security to work in Azure SQL databases
Bringing row-level security to Azure SQL databases
Dig Deeper on SQL Server Security
Related Q&A from Steven Andres
Learn how to create a SQL Server user authentication schema having password and tracked data changes requirements and how it involves Windows ... Continue Reading
Learn why SQL Server 2000 connection is lost on the client side when database administrator changes 'SA' password on the SQL Server domain. Continue Reading
Find how to create a SQL Server 2000 login account and then set user account rights to specific databases with "db_owner." Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.