在一个环境中执行 SQL CLR 函数时出现错误 6522,而它在另一个环境中运行
Error 6522 while executing a SQL CLR function on one environment whereas its working on another
我的应用程序在存储过程的 select 语句中执行 CLR 函数(从 SQL UDF 中)时抛出以下错误。
A .NET Framework error occurred during execution of user-defined routine or aggregate "clr_name":
System.Exception: clr_name failed: id = 7
System.Exception:
at ABC.SQLCLR.XYZ.XX.clr_name(decimal param1, integer param2)
SQL 分析器中的错误代码显示为 6522
代码在我们调用在
内调用 CLR 的 UDF 处中断
SELECT ColumnId, RowId, [OtherDB].dbo.udf_callingCLRWithin(ColumnID, RowID,[XYZ]) AS [XYZ]
FROM tableName
UDF 签名
ALTER FUNCTION [dbo].[udf_callingCLRWithin](Parameters)
RETURNS [numeric](28, 12) WITH EXECUTE AS CALLER
AS
EXTERNAL NAME <AssemblyPath>.[clr_*****]
但这只发生在一种环境中,而不会发生在另一种环境中。
我的应用程序和数据库位于不同的服务器上,这对所有环境都很常见。
我发现 提出了类似的问题,但标记为答案的解决方案主要是关于 CLR 中的解决方案。
但我无法访问 CLR 代码,我也不认为这是代码的问题,因为它在其他环境中运行良好。
到目前为止我已经验证的事情:
- 调用 CLR 的数据库有 'TRUSTWORTHY TRUE'
- 我检查过服务器上启用了 CLR
知道 CLR 代码在其他服务器上运行良好这一事实,我可以在数据库服务器上具体检查什么?
.Net Framework 和 SQL 版本有什么作用吗?我应该检查什么以及在哪里检查?
这个问题出乎我的意料。
我分享的抛出错误的 SQL 语句是从 table 中读取的,实际上它是通过从链接服务器获取数据生成的。早些时候,我认为这不重要,所以我在起草问题时过滤了它。原来是这样,
SELECT * INTO #tablename
FROM OPENQUERY([Linked-Server-name], 'SELECT * FROM RemoteDB.dbo.Remotetable')
SELECT ColumnId, RowId, [OtherDB].dbo.udf_callingCLRWithin(ColumnID, RowID,[XYZ]) AS [XYZ]
FROM #tableName --This statement breaks here and throws error
这里的代码中断了 ,因为链接服务器是 SQL 2014 年,而在 'TableName' 上执行 CLR 的主服务器是 SQL 2012 年。当我将链接服务器更改为与主服务器相同的 SQL 版本时,代码 运行 非常好。
不确定这是否特定于 SQL 2014 或 SQL 的任何不同版本。
我的应用程序在存储过程的 select 语句中执行 CLR 函数(从 SQL UDF 中)时抛出以下错误。
A .NET Framework error occurred during execution of user-defined routine or aggregate "clr_name":
System.Exception: clr_name failed: id = 7
System.Exception:
at ABC.SQLCLR.XYZ.XX.clr_name(decimal param1, integer param2)
SQL 分析器中的错误代码显示为 6522
代码在我们调用在
内调用 CLR 的 UDF 处中断SELECT ColumnId, RowId, [OtherDB].dbo.udf_callingCLRWithin(ColumnID, RowID,[XYZ]) AS [XYZ]
FROM tableName
UDF 签名
ALTER FUNCTION [dbo].[udf_callingCLRWithin](Parameters)
RETURNS [numeric](28, 12) WITH EXECUTE AS CALLER
AS
EXTERNAL NAME <AssemblyPath>.[clr_*****]
但这只发生在一种环境中,而不会发生在另一种环境中。 我的应用程序和数据库位于不同的服务器上,这对所有环境都很常见。
我发现
但我无法访问 CLR 代码,我也不认为这是代码的问题,因为它在其他环境中运行良好。
到目前为止我已经验证的事情:
- 调用 CLR 的数据库有 'TRUSTWORTHY TRUE'
- 我检查过服务器上启用了 CLR
知道 CLR 代码在其他服务器上运行良好这一事实,我可以在数据库服务器上具体检查什么?
.Net Framework 和 SQL 版本有什么作用吗?我应该检查什么以及在哪里检查?
这个问题出乎我的意料。
我分享的抛出错误的 SQL 语句是从 table 中读取的,实际上它是通过从链接服务器获取数据生成的。早些时候,我认为这不重要,所以我在起草问题时过滤了它。原来是这样,
SELECT * INTO #tablename
FROM OPENQUERY([Linked-Server-name], 'SELECT * FROM RemoteDB.dbo.Remotetable')
SELECT ColumnId, RowId, [OtherDB].dbo.udf_callingCLRWithin(ColumnID, RowID,[XYZ]) AS [XYZ]
FROM #tableName --This statement breaks here and throws error
这里的代码中断了 ,因为链接服务器是 SQL 2014 年,而在 'TableName' 上执行 CLR 的主服务器是 SQL 2012 年。当我将链接服务器更改为与主服务器相同的 SQL 版本时,代码 运行 非常好。
不确定这是否特定于 SQL 2014 或 SQL 的任何不同版本。