问题标签 [clrstoredprocedure]

我有一个带有表值函数的 SQL Server 2008 R2 CLR 数据库项目。表值函数运行选择查询以执行其逻辑。我想在 VS 2010 中调试它，这样我就可以单步调试我的代码，但是对于我的生活，我不知道该怎么做，而且我已经阅读了无数的博客。

我还尝试从服务器资源管理器中选择该功能并单击上下文菜单上的“进入”选项，但我只是收到一个错误，即我们的开发服务器上没有设置远程调试。我是否需要启用远程调试，如果需要，我该如何以正确的方式进行操作以使其正常工作。我已经在这几天了，我准备把头发拉出来。我什至把我的周末都花在了这个上面。请任何帮助将不胜感激。

我有一个通用的 clr 触发器，可以在插入、更新、删除时附加到不同的表。例如

...所以它不是特定于某个表的。如何在 clr 触发器中找到触发器正在更新的 sql 对象？

我需要从 SQL Server 上下文中执行 SFTP。我可以使用 MS 库进行 FTP，但它们不支持 SFTP。

所以我下载了 Rebex，并整理了一个示例项目，并尝试将它作为 CLR 存储过程安装到 SQL Server 中。

执行此操作时，SQL Server 会给出以下消息：

消息 6218，第 16 级，状态 2，第 3 行

为程序集“RebexTest”创建程序集失败，因为程序集“Rebex.Common”验证失败。检查引用的程序集是否是最新的并且受信任（对于 external_access 或不安全）以在数据库中执行。如果有任何 CLR 验证程序错误消息将跟随此消息

[ : Rebex.Security.Certificates.CertificateStore::Exists][mdToken=0x60003b0]
[offset 0x000000C7] 方法不可见。

有没有办法解决这个问题，以便我可以将它安装到 SQL Server 中？

我实现了一个 CLR 存储过程的“HelloWorld”示例，它工作正常。

然后我更改了代码，重新编译并重新运行它，得到的是旧结果，而不是新结果。

示例代码更改（所有其他代码都在上面的链接中）：

前：

后：

除了回收 SQL 来加载新的程序集，还有什么不足之处吗？

我正在使用 C# .NET 3.5 CLR 存储过程将数据导入 SQL-Server 2008 R2。理论上。

作业失败并显示以下消息：

这似乎是我的代码中的一个错误，所以我尝试调试 clr 程序集，但调试中止并显示以下消息：

谷歌搜索似乎表明这是一个内存问题，但我找不到适合我的问题的匹配项。

更新：我已经处理了第一个错误，但仍然无法调试 CLR 程序集，这就是这个问题的意义所在。调试中止通常围绕以下代码：

大多数情况下，我可以继续单步执行代码，直到proc.WaitforExit();在某些调试中，我已经完成了几行GC.Collect()，而且我也曾经在proc.Start(). 这不是代码的语法，因为它在我第一次运行时工作，但是当第二次调用该方法时，调试中止。当我在服务器上执行代码时，一切正常。

为了简单起见，这里是我正在尝试做的一个例子：

我用 C# 编写的 CLR 库（它是线程安全的，即使我没有在示例中显示它）：

编译后，我将其导入我的 SQL Server（使用 Microsoft SQL Server Management Studio）：

我导入存储过程：

最后，我有一个调用存储过程的 SQL 脚本：

现在的问题是：每次我调用存储过程（如上所示）时，都会创建一个新的 Session 对象（我知道，因为我看到在另一端打开了多个 TCP 连接）。

如何阻止 SQL Server 多次加载我的库，以便它实际执行“静态”对象范例？我只希望创建单个“会话”，直到 SQL Server 进程终止，而不是每次调用存储过程时都创建一个静态对象。

谢谢你。

更多细节（不确定它们是否有必要）：我的“会话”对象是从另一个库加载的（所以我在技术上加载了 2 个 DLL，但在上面的示例中只显示了一个以保持简单），然后依次包装（并加载）一个本机 DLL，不确定此信息是否相关，但我想我会添加它。

编辑：我还想补充一点，如果我在同一个 SQL 脚本中多次调用我的存储过程，则会创建一个 Session 对象。每次我用多个存储过程调用调用该脚本时，都会创建一个新的 Session 对象。

我有一个将存储过程部署到服务器的 SQL CLR 项目。2 年来，我一直能够右键单击项目并进行部署。昨天，当我尝试这样做时，我开始出现错误。上周我能够部署新版本，但本周不行。

我一直在四处寻找，找不到任何有关错误的信息。自从我上次部署以来，sql server 上没有任何更新。我已经卸载了我的机器上的 VS2010 更新以及 .net 更新，但没有做任何事情。我没有卸载的唯一更新是办公室更新，我认为这不是问题。

有任何想法吗？我试过在 sql 机器上重置权限。手动删除存储过程并重新部署。我已经回到项目的先前版本并尝试部署。重新启动计算机上的 SQL Server 服务。

视觉工作室 2010 SQL Server 2008

谢谢

.Net 代码如何检测 SQL 服务器何时决定卸载 AppDomain？

SQL 服务器有时会出于各种原因决定卸载 AppDomain，将其状态更改sys.dm_clr_appdomains为E_APPDOMAIN_DOOMED：

AppDomain 计划卸载，但当前有线程在其中执行。

当“计划卸载 AppDomain”或在 CLR 代码中检测此状态的方法时，CLR 代码中是否会引发事件？

如果我知道代码作为哪个 AppDomain 执行，我可以定期轮询状态sys.dm_clr_appdomains，但这不会在SqlContext对象中公开。我不确定是否sys.dm_clr_appdomains.assembly_name与AppDomain.FriendlyName.

如果可能的话，我已经存储了永远运行的过程（当数据可用时，它们会将数据推送到客户端）。由于当 SQL Server 决定卸载 AppDomain 时这些线程仍在运行，因此 AppDomain 永远不会卸载，线程永远不会停止执行，来自客户端的连接永远不会关闭。

编辑：

匹配中的 and ，appdomain_id我appdomain_name使用以下 CLR 存储过程进行了检查：sys.dm_clr_appdomainsSystem.AppDomain.IdSystem.AppDomain.FriendlyName

因此，在等待下一个事件超时后轮询状态绝对是可能的，但它会留下与程序集状态的最大轮询频率相关的不希望的延迟量。

编辑2：

AppDomain.DomainUnload更改为其创建 AppDomain 的程序集时不会引发该事件。我不知道当 Sql Server 决定卸载 AppDomain 时是否会引发它。

运行OnUnloadsproc 然后更改程序集会导致ALTER ASSEMBLY命令挂起或 AppDomain 在没有引发事件的情况下注定失败。

我正在使用 microsoft sql server 2008。在执行 CLR 过程时，我收到以下错误。

尝试加载程序集 id 65547 时，Microsoft .NET Framework 中发生错误。服务器可能资源不足，或者程序集可能不受 PERMISSION_SET = EXTERNAL_ACCESS 或 UNSAFE 的信任。再次运行查询，或查看文档以了解如何解决程序集信任问题。有关此错误的更多信息：System.IO.FileLoadException：无法加载文件或程序集“clrprocedure，版本=0.0.0.0，文化=中性，PublicKeyToken=null”或其依赖项之一。发生与安全有关的错误。（来自 HRESULT 的异常：0x8013150A） System.IO.FileLoadException：
在 System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark & stackMark, Boolean throwOnFileNotFound, Boolean for Introspection) at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark & stackMark, Boolean for Introspection ) 在 System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) 在 System.Reflection.Assembly.Load(String assemblyString)

请建议。

我正在通过 CLR 程序集将平面文件导入数据库。
对于平面文件中的每一行，程序集都会进行一些质量检查。我注意到在 DataTables 中存储 DB 表并查询这些 DataTables 比直接查询 DB 要慢得多。另一方面，HashSet 似乎与查询数据库一样快。

目前，我的代码有时会将数据加载到 HashSet 中并为每一行查询 HashSet，有时它会为每一行单独检查数据库。例如，当我检查源行中的一个键是否存在于数据库中以获取 ~10 000 个源行和 ~1000 个可能的正确键时。
HashSet :
+ 我只查询数据库一次，程序集可以对 HashSet 执行检查。
- 为什么要复制数据库中已经存在的东西？
查询 DB：
+ DB 保存表的结构，并针对此类查询进行了优化。
- 我必须管理数据库连接，这可能包括多次打开/关闭数据库连接。

我想标准化我的代码，并且需要帮助决定使用哪个选项？我没有看到我的表现有什么不同。如果从 CLR 程序集打开 DB-Connection 不是问题，那么我更愿意查询 DB，因为我可以将 SQL 代码写入我的 CLR 程序集并执行它，而不必编写多个对象.

是否有技术原因使用其中一个？
编码风格的推荐？

注意：我正在处理静态数据，因此在导入程序集运行时我不需要担心数据更改。

也许是一个相关的问题。