SQLServer报错15599本地临时对象不能设置权限和审核，怎么处理修复支持远程操作

根据微软官方文档和SQL Server技术社区（如Stack Overflow、CSDN）的普遍解释，错误15599的根本原因在于，您尝试对一个以开头的本地临时表（Local Temporary Table）进行需要持久化元数据（即表的结构、属性等定义信息）的操作，例如使用GRANT、DENY或REVOKE语句来设置权限，或者配置审核（Audit），SQL Server的设计决定了本地临时表无法支持这些操作。

错误原因详解

来源自SQL Server引擎的内部机制：本地临时表（#TempTable）的生命周期仅限于当前用户会话，当创建该表的会话结束时（关闭查询窗口或断开数据库连接），SQL Server会自动删除这个临时表及其所有数据，这种“临时性”是其核心特征。

权限设置和审核规则是数据库级别的、需要持久化的元数据，它们需要被记录在系统表（如sys.objects, sys.database_permissions）中，以便数据库引擎在每次对象被访问时进行校验，将一个“短暂存在”的临时对象与“需要持久记录”的安全元数据绑定在一起，在逻辑上是矛盾的，SQL Server引擎为了避免这种不一致性，直接禁止了此类操作,并通过错误15599来提示用户。

您不能给一个“随时会消失”的东西制定一个“永久有效”的访问规则，这就像试图给沙滩上的沙堡安装一把固定的锁，沙堡被潮水冲走后,锁也就失去了意义。

处理与修复方法

既然问题的根源是对象类型不匹配，那么解决方案的核心就是避免对本地临时表执行权限和审核操作，以下是几种常见的处理思路,具体选择取决于您的实际业务需求。

使用全局临时表（##GlobalTempTable）

• 操作：将您的本地临时表（#TempTable）替换为全局临时表（##GlobalTempTable），全局临时表以双井号（）开头，它对所有用户会话都可见,直到创建它的会话结束且所有其他会话不再引用它时才会被删除。
• 原因：全局临时表的生命周期比本地临时表更长，其元数据在数据库中是持久存在的（尽管表本身仍是临时的），SQL Server允许对其设置权限。
• 步骤：
  1. 在创建表时，将表名从#YourTable改为##YourTable。
  2. 再执行您的GRANT等权限设置语句。
• 重要注意事项：
  • 命名唯一性：全局临时表名必须在整个SQL Server实例内唯一，如果两个不同的会话尝试创建同名的全局临时表，后者会失败，通常需要在表名中加入会话ID（如##TempTable_ + @@SPID）或GUID来确保唯一性。
  • 安全性：因为全局临时表对所有连接都可见，可能会带来意外的数据访问或冲突,需要谨慎管理。
  • 这通常不是最佳实践,除非您的场景确实需要跨会话共享临时数据并控制权限。

使用永久表（Permanent Table）

• 操作：如果您的数据需要被多个会话或用户以受控的权限访问，并且其生命周期超出了单个会话,那么最直接可靠的方法是使用普通的永久表。
• 原因：永久表完全支持所有数据库安全功能，包括权限、审核、索引、触发器等。
• 步骤：
  1. 创建一个不以或开头的普通表。
  2. 根据需要对该表设置精细的权限（GRANT, DENY, REVOKE）。
  3. 使用完毕后，如果数据不再需要，可以显式地使用DROP TABLE语句删除它,您也可以设计一个定时作业来清理过期数据。
• 优势：这是最规范、最可控的方式,它彻底避免了临时表的限制。

重构应用程序逻辑，将权限控制上移

• 操作：不直接对临时表本身设置权限，而是通过控制对创建和操作临时表的存储过程的权限来间接实现安全目标。
• 原因：这是处理此类问题非常常见且推荐的最佳实践，临时表通常是在存储过程或脚本内部使用的中间对象，最终用户或应用程序只需要执行存储过程的权限,而不需要直接访问临时表。
• 步骤：
  1. 将创建临时表、操作数据的所有逻辑封装在一个存储过程中。
  2. 对这个存储过程设置执行权限（GRANT EXECUTE ON SchemaName.ProcedureName TO UserName）。
  3. 确保存储过程内部使用了EXECUTE AS OWNER子句或类似的上下文切换，使得过程在具有足够权限的账户下运行,从而能够顺利创建和操作临时表。
  4. 最终用户只有执行存储过程的权限，无法直接看到或操作临时表，从而实现了安全控制，审核也可以设置在存储过程的执行上,而不是脆弱的临时表上。
• 优势：安全性高，逻辑清晰，符合数据库封装原则,是应对错误15599最优雅的解决方案。

支持远程操作”的说明

错误消息或需求中提到的“支持远程操作”通常是一个误解，这个错误本身与操作是本地还是远程发起无关，无论您是通过SQL Server Management Studio (SSMS) 在本地服务器上连接，还是通过应用程序从远程客户端连接，只要执行的T-SQL语句是“对本地临时表设置权限”,都会触发15599错误。

修复此错误的方法（如上所述）是通用的，适用于任何连接方式，一旦您采用了上述任何一种方法（特别是方法二或方法三），您的应用程序或脚本就可以在任何地方（本地或远程）正常运行,因为它不再包含会引发15599错误的不合法操作。

面对SQL Server错误15599，请不要试图寻找“破解”方法让本地临时表支持权限设置，因为这违背了数据库引擎的基本设计,正确的处理路径是：

1. 评估需求：您的数据是否需要跨会话共享？生命周期多长？
2. 选择方案：
   • 需要简单跨会话且不常使用 -> 全局临时表（方法一）,但需注意唯一性和安全风险。
   • 数据生命周期较长或需要稳定权限 -> 永久表（方法二）。
   • 最佳实践，实现逻辑与安全解耦 -> 封装到存储过程并控制过程权限（方法三）。

通过以上任何一种方式，您都可以有效地解决错误15599，并构建出更健壮、更安全的数据库应用。