Column Level Permissions

Categories: News, Professional, Scripts, SSC
Comments: No Comments
Published on: September 19, 2011

Did you know that you can grant permissions down to the column level in SQL Server?   Well, if you didn’t know that – you do now.

It is actually rather simple to grant permissions at the column level.  This can be demonstrated by the following script.

[codesyntax lang=”tsql”]


If you want to check out more on that syntax, read here.

And then…

Why is it important to know that you can do this?  Well, it is quite possible you have some of these permissions already in place.  It is possible you may have inherited something like this.  Just maybe there is a business requirement requiring that certain users or groups only have access to certain data within certain columns.

That brings up a new problem then.  How do you find out what columns have specific permissions applied to certain users?  Well, that is actually pretty straight forward.  We can query the system views and determine column level permissions.

[codesyntax lang=”tsql”]


The previous query is a really simple version of how to find this information.  As you can see, I am simply returning the UserName, TableName and ColumnName along with the permission in effect on that column.

You should also be able to see that the mapping between these system views is pretty straight forward as well.  Major_id maps to object_id and column_id maps to minor_id.


This query can be of good use to determine permissions in place for columns in tables within your database.  Furthermore, you can even use this query to simply test your curiosity as you check to determine what has been put into effect in the databases you manage.

There are more complex methods to determine these permissions.  With there being more complex methods, I am sure there are also some easier methods.  Let me know what you do to query these permissions.

No Comments - Leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *

September 2011
« Aug   Oct »


  • @Lee____Cam: I've managed to drop my AG now and recovered my do but it won't allow the recreation of the AG. Looks like it's failing at the FCM #sqlhelp
  • @Lee____Cam: I have a 2 note always on ag, both showing not synchronizing/recovery pending. I can't get them online or remove the AG. Any ideas #sqlhelp
  • @SQLSoldier: @mvelic Yes, but then I pointed out that they were using nolock and SSIS isn't. The matching records were not committed. #sqlhelp #TrueStory
  • @mvelic: It's just maddening because this lookup has *always* worked in the past. It's just now deciding to not recognize matches. #sqlhelp
  • @mvelic: Has anyone just seen an SSIS Lookup fail to make matches? You know the matches exist, but it doesn't connect them and it fails? #sqlhelp
  • @banerjeeamit: @MattPgh No. Current processing report is not visible. This is visible in RunningJobs table but not the stats breakdown. #sqlhelp
  • @forhakim: #sqlhelp in Visual Studio SSDT is there a way to make it NOT show table designer, only the script, when I edit a table?
  • @MattPgh: @banerjeeamit Will the current report show up in ExecutionLog? whatever processing is happening did not finish yet. #sqlhelp
  • @banerjeeamit: @MattPgh Look at the time processing and rendering in the logging table: #sqlhelp
  • @banerjeeamit: @MattPgh Also, CPU time can be consumed due to rpt processing. This is available thru the ExecutionLogStorage table #sqlhelp

Welcome , today is Saturday, October 10, 2015