June 18, 2016 at 11:35 am
Comments posted to this topic are about the item Column Level Permissions and DENY
June 18, 2016 at 10:08 pm
Good question, thanks steve.
Have found this link highlight ,order of DENY and GRANT.
http://www.sqlmovers.com/deny-select-on-table-grant-select-on-columns/
J.
June 20, 2016 at 12:33 am
This was removed by the editor as SPAM
June 20, 2016 at 1:10 am
It's surely good to have such a fine level of granularity to tune users access rights. Even though we don't have any use cases for such fine-tuning atm, I can easily imagine organizations where this is highly relevant.
June 20, 2016 at 5:44 am
mjagadeeswari (6/18/2016)
Good question, thanks steve.Have found this link highlight ,order of DENY and GRANT.
http://www.sqlmovers.com/deny-select-on-table-grant-select-on-columns/
J.
Thanks for your interesting note and the link. For the SELECT * you can use GRANT on table level:
GRANT SELECT ON dbo.Employee TO AEUser
GO
June 20, 2016 at 6:12 am
I would have thought the lack of a GO after the GRANT would have left permissions unchanged for the final SELECT. This is something I've run into with SQL Server 2008, has it changed in subsequent versions?
June 20, 2016 at 7:23 am
roger.plowman (6/20/2016)
I would have thought the lack of a GO after the GRANT would have left permissions unchanged for the final SELECT. This is something I've run into with SQL Server 2008, has it changed in subsequent versions?
This isn't one batch. The code is being run in sections, which is why the text breaks each part up.
June 21, 2016 at 10:53 am
Great question, Steve. Permissions can get complicated, but it still boils down to a few simple rules. Thanks.
June 22, 2016 at 1:37 pm
This took a good deal of my lunch break. Thanks, Steve! (No sarcasm!)
Edit: typo
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply