对象上的权限，但那是被动反应的方式而非积极主动的方式――你是在查找当前访问级别上哪里出错了，而不是事先停止不希望发生的访问。
最后，但并非最不重要的，是AS关键字。该关键字处理的是一个登录名属于多个角色的问题。
接下来，我们来看一、两个例子。后面将看到，我们已 经创建的TestAccount账户，基于其是Public角色（所有的数据库用户都属于的东西，并且，无法从中移除）中的成员而拥有了一些访问权限。然 而，尚有大量的项目是TestAccount不具有访问权限的（由于Public是TestAccount唯一属于的角色，因此，Public也不具有那 些权限）。
先从以TestAccount用户登录开始。然后在Region表上尝试一个SELECT语句：
很快，你将收到来自SQL Server的消息，告知：你正在尝试去到你所不应该访问的地方。
单独以sa登录――如果你愿意，也可以在同一个查询编辑器实例中，通过选择菜单“文件”→“连接”，来完成这件事情。然后，为新的连接选择“SQL Server身份验证”，并用正确的密码以sa身份登录。现在，执行GRANT语句：
接着，切换回TestAccount连接（要记住，以什么用户进行连接的信息显示在连接窗口的标题栏中），然后，再尝试执行SELECT语句：这一次，得到了好得多的结果：
我们继续尝试另外的语句。这一次，我们在EmployeeTerritories表上运行相同的测试和命令：
该语句执行失败――这同样是由于你不具备相应的权限所致，因此，授予用户该表上的权限：
然后，再次运行SELECT语句，一切进展顺利：
不过，若要再添加一点变化，尝试在这个表中执行INSERT：
SQL Server立即会让我们走开――我们不具备必要的权限，因此，授予用户相应的权限（使用sa连接）：
现在，再次运行INSERT语句：
一切进展顺利。
2．DENY
DENY明确阻止用户获得目标对象上指定的访问 权限。DENY的关键所在是，它将覆盖任何GRANT语句。由于用户可以属于多个角色（马上将对此进行讨论），因此，一个用户可能属于被授予了访问权限的 角色，但同时又受DENY的影响。如果用户个人的权限和基于角色成员身份所获得的权限混合在一起，DENY和GRANT同时存在于其中，那么DENY总是 优先的。简言之，如果用户或用户所属的任何角色在权限问题上有DENY出现，则用户将不能使用在那个对象上的访问权限。