SQL Server视图权限不继承基表，必须显式授予SELECT权限；若视图跨库、调用函数或启用SCHEMABINDING，还需额外授予目标库SELECT权、函数EXECUTE权及依赖对象对应权限，并确保架构VIEW DEFINITION权限可用。
SQL Server视图权限不继承基表，必须显式授权
用户执行 SELECT * FROM dbo.v_sales 报错 “The SELECT permission was denied on the object”，但查 dbo.Sales 表完全正常——这几乎肯定是视图本身没授 SELECT 权限。SQL Server 不会把基表权限“穿透”到视图，哪怕视图只 SELECT 一张表、甚至只 SELECT 一个字段。
解决方法非常直接：
- 用
GRANT SELECT ON [schema].[view_name] TO [user]单独授权，例如：GRANT SELECT ON dbo.v_sales TO app_reader - 若视图跨库（如引用
OtherDB.dbo.Customers），目标库中该用户也必须有SELECT权限，不能只在当前库操作 - 避免依赖
db_datareader角色：它只覆盖表，不覆盖视图，开了反而掩盖权限设计缺陷
视图调用函数或存储过程时，EXECUTE 权限容易漏掉
如果视图定义里用了自定义函数（比如 dbo.fn_format_date()）或内联表值函数（ITVF），仅给视图授 SELECT 权限是不够的。SQL Server 会在执行时检查调用链上每个对象的权限。
常见错误现象：
- 查询视图返回空结果或报错 “The EXECUTE permission was denied on the object 'fn_format_date'”
-
SHOW CREATE VIEW不适用（SQL Server 用sp_helptext或sys.sql_modules查定义） - 用
SELECT definition FROM sys.sql_modules WHERE object_id = OBJECT_ID('dbo.v_sales')确认是否含函数调用 - 补授权：
GRANT EXECUTE ON dbo.fn_format_date TO app_reader
架构（schema）权限缺失导致“看不见”视图
用户能连上数据库、能看到 sys.objects 里有视图记录，但 SSMS 物件总管里不显示，或者 SELECT 时报“对象不存在”——很可能是缺少对视图所在架构的 VIEW DEFINITION 权限。
尤其当视图不在 dbo 架构下（比如 reporting.v_summary），而用户只被加进 db_datareader，就无法枚举该架构下的对象。
补救方式：
- 授予架构级查看权：
GRANT VIEW DEFINITION ON SCHEMA::reporting TO app_reader - 或更细粒度地只给视图定义权：
GRANT VIEW DEFINITION ON reporting.v_summary TO app_reader - 注意：
DENY VIEW DEFINITION优先级高于 GRANT，务必先查是否有冲突的 DENY
WITH SCHEMABINDING 视图触发底层对象权限检查
带 WITH SCHEMABINDING 的视图会强制绑定其引用的所有表、函数、列结构。这意味着：即使你已对视图授了 SELECT，只要调用者对其中任意一个被绑定对象（比如 sales.Orders）没有 SELECT 权限，查询仍会失败。
这不是 bug，是 SQL Server 的安全设计。排查步骤：
- 查视图是否绑定：
SELECT uses_schema_binding FROM sys.views WHERE name = 'v_summary'（返回 1 表示启用） - 查它依赖哪些对象：
SELECT referenced_entity_name, referenced_schema_name FROM sys.dm_exec_describe_first_result_set(N'SELECT * FROM dbo.v_summary', NULL, 0) - 逐个确认调用者对这些对象是否有对应权限；必要时补
GRANT SELECT ON ...或改用非绑定视图
最隐蔽的坑在于：权限链断裂不是发生在视图层，而是藏在 sys.dm_exec_describe_first_result_set 暴露的依赖树深处。不主动展开查，很容易卡在“明明授了权怎么还报错”上。
