问题标签 [sqlclr]

我正在研究 SQL Server 2005/2008 中可用的一些较新的技术。我的大多数应用程序都是用 C# 编写的，并且通常具有数据库组件。我在 Google 上找到的大部分内容都是基本的，“这就是您设置 CLR UDT 的方式”。我对它们的实际应用和使用有一些一般性的问题。

• CLR 托管的 UDT 是否常用于应用程序？大或小规模
• 使用它们是否存在性能问题？
• DBA 通常只喜欢使用内置类型吗？

它们似乎是一种将物体塞进桌子的方法。我是否正确假设由于使用而简化解决方案的实际问题范围很小？

我们正在尝试在 SQL Server 2005 机器上创建 C# CLR 存储过程。C# 代码通过 OLEDB 驱动程序连接到外部数据源以获取数据表。它已经在单独的控制台应用程序上进行了测试，并且可以正常运行。（OLEDEB 驱动程序是连接到专有数据库的专有驱动程序......）

在 SQL Server 上，我们已经为程序集设置了 EXTERNAL 权限级别，它是 StrongNamed 并且已经在 SQL Server 中为其创建了一个 ASSYMETRIC KEY。

当我们尝试执行该过程时，我们会遇到以下两个问题：

• 用于联系 OLEDB 的凭据是运行 SQL 服务的凭据，而不是 sql contect 中已登录用户的凭据

• 提出了一个 .NET 框架：

  System.Security.SecurityException：请求 System.Data.OleDb.OleDbPermission 类型的权限

似乎我们无法为进程授予运行 oledb 驱动程序所需的权限。要么是缺少配置，要么是我们做错了什么。将权限级别设置为 UNSAFE 也不是一种选择......

有没有人对这类问题有任何经验。欢迎任何意见！

我知道它不受支持，而且我知道这甚至不是一个非常好的主意。但是，我想在 SQL 表值函数中有一个 WCF 客户端。

我（似乎）注册了正确的程序集，但是在运行我的客户端时 - 我收到了 WCF 错误：

Sql Server 之外的测试似乎有效——我什至没有看到 WCF 客户端尝试建立 TCP 连接。

不确定这是 WCF 还是 SQL CLR 问题，因为我对这两者都是新手.....

编辑：我了解所需的 System.ServiceModel 及其无数程序集不在经过审查的 Sql CLR 列表中。然而，

“仍然可以从您的托管存储过程、触发器、用户定义的函数、用户定义的类型和用户定义的聚合中调用不受支持的库。不受支持的库必须首先使用 CREATE ASSEMBLY 语句在 SQL Server 数据库中注册，在它可以在你的代码中使用之前。任何在服务器上注册和运行的不受支持的库都应该经过审查和测试，以确保安全性和可靠性。

是否有相当于

哪个可以从 CLR (C#) 代码中调用？

我正在尝试在我的函数中输出一些调试信息。我无法运行 VS 调试器，因为这是远程服务器。

谢谢！

从 tsql 调用 ole 对象是否存在任何固有问题？我遇到了一个我想仅使用存储过程来解决的问题，使用 ole 对象而不是用基于 clr 的语言编写它有什么需要担心的吗？

如何从 SQL CLR 例程中引发 SQL Server 错误事件（类似于 RAISERROR）？

这是这种情况：

我有一个 Trigger.dll 和一个 Trigger.XmlSerializer.dll。

我使用 CREATE ASSEMBLY 在 MSSQL 中注册它们。

现在，我已经编译了两者的新版本。

我想使用 ALTER ASSEMBLY 来更新它们，但是您一次只能更新一个。如果您尝试更新具有依赖关系的一个，它会抱怨。这样做有什么诀窍？

我不想删除并重新创建，因为我必须删除所有触发器等，并且存在数据库停机时间。

我有一个 SqlServer 项目，对表值函数进行了非常简单的测试：-

请注意，连接上的 Open 当前已被注释掉。部署后，我可以在 SQL 中像这样执行：-

一切正常。

现在我取消注释con.open()它失败了： -

在这种情况下不允许数据访问。上下文要么是未使用 DataAccessKind.Read 或 SystemDataAccessKind.Read 标记的函数或方法，要么是从表值函数的 FillRow 方法获取数据的回调，要么是 UDT 验证方法。

我看不出问题出在哪里，TestConn 函数得到了DataAccessKind.Read.

任何人都知道出现此错误的任何其他原因吗？

我正在考虑从 Sql Server 2005 中的 UDF 访问一些 CLR 代码。

我听说过 CLR 代码中抛出的未处理异常会导致服务器瘫痪的故事。

显然我的函数将包含一个 try-catch 块。但是，某些异常（stackoverflow）可以跳过捕获。

有没有人有一套指导方针可以完全消除（或最小化）我的 CLR 代码导致服务器崩溃的风险。

我正在尝试将一些现有的 C# 代码转换为 CLR 存储过程。要使用的明显连接字符串是上下文连接（“上下文连接 = true”）。

我遇到的问题是某些事情显然不适用于这种连接类型。最新的是 SqlConnection.GetSchema 方法失败。该错误只是说它在上下文连接上不可用。是否有一个在上下文连接上不起作用的列表？