SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Granting or denying permissions to all of the tables within a database

When granting or denying permissions to the tables within a database you have two options. You can either add the user/role to one of the preexisting database roles

  • Db_datareader – grants SELECT to all tables & views in a database
  • Db_datawriter – grants INSERT, UPDATE and DELETE to all tables & views in a database
  • Db_denydatareader – denys SELECT to all tables & views in a database
  • Db_denydatawriter – denys INSERT, UPDATE and DELETE to all tables & views in a database

Or you can grant those permissions explicitly by granting/denying SELECT, INSERT, UPDATE and DELETE to the database itself. Unlike the roles you can also grant these permissions at the schema or even table/view level.

So what’s the difference? The code is obviously different but not really a big deal either way.

EXEC sp_addrolemember ‘db_datawriter’,’username’;  
	-- Add a user to a role
GRANT SELECT TO username; 
	-- Grant a permission to a user

In terms of access there is no real difference. A user granted SELECT on the database has exactly the same permission as one added to the db_datareader role.

The biggest difference in my experience is when you go to look at what permissions a user has. Role membership is found in sys.database_role_members and general permissions are found in sys.database_permissions.




Note that because I granted the permissions at the database level I have to look at the permissions tab on the database properties page not the securables tab on the user properties page. Had I granted the permissions at a lower level, say SELECT on the dbo schema, then I would have looked in the securables tab.

So which should you use? Really it doesn’t matter as long as you are consistent. My personal preference is to grant specific permission to roles then assign the roles to AD groups. The specific permissions because they are more granular and I can grant INSERT and UPDATE without granting DELETE, the roles make it easier to manage over the long run by giving you a single place with a logical name to grant a set of permissions. For example I can create roles that match a given position in the company. DBOperator1 and DBOperator2 for example. They may have almost identical permissions but DBOperator2 has the ability to do deletes or run some extra stored procedures. The AD groups is also an ease of management thing. My company has a “security team” that handles AD membership and checks to see if an individual is allowed to be in a given group. Since we already have people doing that work why should I want to add those tasks to my workload?

Remember the most important thing is to be consistent. If you have some users/groups in roles and others with direct permissions you are going to have a harder time down the road.

Filed under: Microsoft SQL Server, Security, SQLServerPedia Syndication, SSMS Tagged: database permissions, microsoft sql server, security, SSMS


My name is Kenneth Fisher and I am Senior DBA for a large (multi-national) insurance company. I have been working with databases for over 20 years starting with Clarion and Foxpro. I’ve been working with SQL Server for 12 years but have only really started “studying” the subject for the last 3. I don’t have any real "specialities" but I enjoy trouble shooting and teaching. Thus far I’ve earned by MCITP Database Administrator 2008, MCTS Database Administrator 2005, and MCTS Database Developer 2008. I’m currently studying for my MCITP Database Developer 2008 and should start in on the 2012 exams next year. My blog is at www.sqlstudies.com.


Leave a comment on the original post [sqlstudies.com, opens in a new window]

Loading comments...