问题标签 [sqlclr]

我正在尝试创建一个 CLR UDF，它接受一个字符串值，如“Mike|John|Smith”。在 UDF 中，我解析出值并在 DataTable 中返回它们。C# 代码构建良好，我可以毫无问题地在 SQL 中创建指向 DLL 的程序集。

根据此消息来源，当我尝试告诉 SQL Server 如何将 Transact SQL 请求与 CLR 函数匹配时，问题就出现了。http://www.setfocus.com/technicalarticles/clrfunctionforsqlserver_2.aspx

或者我什至必须这样做？基本上我想接受一个字符串，解析出分隔值并将它们放入一个具有 3 个不同列 FN、MN、LN 的 DB 表中。使用 CLR UDF。

我在 MSSQL 2005 Server SQLCLR 中有一个存储过程。是否可以为它定义一个可选参数？如果是这样，怎么做？

由于 stackoverflow 的创始人谈论了能够轻松部署更改，我正在尝试提出一个解决方案来解决我的问题。一个快速的背景是，一个客户联系了我，需要在数据库上完成一些不那么简单但并不难做到的事情（我花了大约一天的时间让这个过程开始工作）。不幸的是，客户需要能够部署这个“修复”大约 20 次，并且没有我的输入，因为他不会为此付费。

我编写了一个 CLR 触发器，它可以完成一些使用 TSQL 否则会非常困难的工作（xml 文档转换......我更擅长使用 CLR 与 TSQL）。部署通常是几行 SQL 并将 dll 转储到我可以钓到的目录中（到目前为止我只从 VS.Net 部署过）。

我需要做的是提供一个 MSI 安装程序，它将文件拖放到文件夹中，并提示用户输入将 CLR 过程连接到正确的数据库/表所需的数据库信息。

过去有没有人这样做过，如果有，你愿意教别人如何做到这一点，这样我就可以完成这个项目吗？

谢谢

1. 我有一个 TSQL 存储过程tsql__sp__A它做两件事：

(a) 创建一个临时表#tempTable，其中包含来自复杂 SELECT 查询的 SELECT 数据。

(b) 为对行参数进行计算的每一行调用 CLR 管理的存储过程clr__sp__B。

问题：是否可以使用相同的连接上下文从 CLR 过程clr__sp__B访问#tempTable ？（不，我不想在托管过程中移动或创建另一个#tempTable ）

谢谢。

我们在 SQL Server 2000中有一个常规的（即非扩展的）存储过程，它调用一个外部 exe。反过来，该 exe 加载来自 SDK 的 .dll 并从中调用一些过程（即 Init、DoStuff、Shutdown）。

我们拥有这个外部 exe 的唯一原因是因为我们不想创建一个会调用 .dll 的扩展存储过程。我们认为，如果 dll 崩溃（不太可能发生但仍然如此），那么 SQL Server 进程也会崩溃，这不是我们想要的。使用外部 exe，只有该 exe 会崩溃。

现在，我们正在升级到 SQL Server 2008并考虑创建一个调用该事物的 CLR 存储过程，从而摆脱 exe。当然，这个 SP 会被标记为 UNSAFE。因此的问题是，与扩展的 SP 方法相比，这样做是否安全（更安全、足够安全等）？

我在 BOL 上找到的唯一相关的事情是：

指定 UNSAFE 允许程序集中的代码对 SQL Server 进程空间执行非法操作，因此可能会损害 SQL Server 的稳健性和可伸缩性

，但我不确定它是否回答了我的问题，因为我不是追求“鲁棒性和可扩展性”，而是追求稳定性和保持事物正常运行。

PS：我们想要摆脱 exe，因为它在管理 SP 权限时会造成不便（你知道，如果你调用包含 xp_cmdshell 的 SP，这些东西会突然适用于你）。

在创建 SQL Server CLR 存储过程时，我注意到我无法像往常一样引用 .net 框架中的任何内容。经过一番阅读，我意识到需要先将程序集加载到数据库中。

因此，我加载了我需要的那些，但由于 P/Invoke 不得不使用 UNSAFE 权限集。我现在可以在我的存储过程代码中引用它们并且一切正常。

但是，当我真的不知道他们在做什么时，我有点担心必须将它们设置为 UNSAFE。所以我的问题是：

可以将 .net 框架加载为 UNSAFE 而不完全按照它在做什么？这样做会如何损害 sql server 的安全性/健壮性/可扩展性（正如微软警告的那样）？

非常感谢。

我们在 CLR 过程中有一个内存数据表。经过大量处理后，DataTable 有很多数据需要加载到数据库中的表中。不幸的是，由于我们使用的是上下文连接， SqlBulkCopy 将无法工作（抛出错误：在上下文限制的上下文连接大纲中，请求的操作不可用 ）。

我们正在考虑建立一个额外的常规连接并使用它来执行 SQLBulkCopy。考虑到在上下文连接上使用常规连接的开销，这似乎相当愚蠢。我们考虑过遍历 DataTable 中的行并为每个行插入一条记录，但它的大小很大，SQLBulkCopy 似乎更合适。

我们没有与 DataTable 结婚，只是在寻找从 CLR 过程将大量数据插入数据库的最佳方法。关于 DataTable 的最后一点说明，它代表底层数据库表，但不通过 DataSet 或 TableAdapter 绑定到表。在 CLR 过程中这样做的方法并不是很明显。这样做并使用 AcceptChanges 或 Update 方法将是一个可接受的解决方案。

我最近在我的 64 位 SQL Server 2005 机器上启用了 CLR，以使用大约 3 个过程。当我运行以下查询以收集有关内存使用情况的一些信息时...

我明白了

129 mb MemoryUsage 和 6.3 gb 保留的虚拟内存

机器的总内存为 21 gig。保留的虚拟内存到底是什么意思，我如何控制分配的大小？6 gig 对于我们正在做的事情来说太过分了，sproc 缓存会更好地利用内存。我担心这个保留的内存会导致交换到页面文件。

请帮我收回对内存的控制权！

谢谢

为什么我不能使用上述方法从框架库中生成非对称密钥（用于安装在 SQL Server 中作为 CLR 函数的参考）。它给出了一个错误：

“在生成非对称密钥期间发生错误。”

如果没有非对称密钥，则需要将数据库设置为可信任才能将程序集添加到 SQL Server (2005)。我意识到框架库不适合在 SQL Server 中使用，但很好奇为什么这不起作用。

目前我们有 MS SQL Server 2005（32 位）。我们有 1 个程序集（并且只有 1 个程序集）用于加密和解密。只有 512 MB 的系统内存分配给 CLR。程序集运行得很慢，我试图排除它是否来自内存。当我在查询分析器（而不是程序集）中运行 SQL 代码时，它运行得很快。我们使用对称密钥和证书进行加密/解密。

是否有推荐的内存量分配给 CLR？如何判断内存分配不足是否会降低此程序集的性能？