是否可以在 SQL Server 2005 中的 CLR 触发器上通过 MSMQ 将消息发送到队列？
我使用的是 SQL Server Project 类型，但 System.Messaging 没有作为我可以添加的参考出现。
基本上，当将一行写入表时，我需要执行某种类型的操作（打印）。生成该行的设备是一个只能执行基本操作的手持扫描仪——其中一个是通过 odbc 写入 SQL Server。最初的想法是轮询表、抓取记录、打印记录、删除记录。这可能会很好，但它似乎是了解消息队列的一个很好的案例和借口。
是的，这是可能的。
不过，我不会在触发器中这样做：TXN 将保持打开更长时间，它是资源密集型的，如果它挂起怎么办等。
您可以通过存储过程进行更新吗？
或者将一行推送到由写入队列的 SQL 代理作业监控的轮询表中？
如果该程序集不受信任，您仍然可以从 SQL Server 访问它 - 它本身不可用，并且必须手动导入并标记为“不受信任”本身。我前段时间在 System.DirectoryServices 上遇到了同样的问题。
关于 System.DirectoryServices，这个人和你有同样的问题，但是以同样的方式执行 CREATE ASSEMBLY 语句应该允许你访问 System.Messaging：
这可能对您有用：http: //support.microsoft.com/kb/555070
这里有一些关于如何处理这个老问题的新想法：http: //nginn.org/blog/ ?p=376
Nginn-messagebus 是我基于 SQL Server 的消息队列项目，针对依赖 SQL Server 的 .Net 应用程序。
通过推送技术很难进行事务处理。
这样做的唯一事务选项是使用 WCF 桥，它需要反过来使用 SQL Server 2008，自 2012 年以来，SQL Server 托管 CLR 阻止的基于 WSDL 的程序集的动态后台编译，我从未破解过如何强制编译这些程序集以避免引用托管 CLR 策略禁止的程序集。
我发现工作的唯一选择（可能是由于我未能找出解决方法）是使用 HttpClient RESTFull 样式的网络客户端和 CLR 集成过程，该过程脱离 SQL Server Broker 激活过程。它工作得非常好，只有一个问题，RESTFull 不支持开箱即用的事务。因此，如果您需要保证消息的传递，您将需要在消息流中的某处进行检查调用。
事实上，为了保护 MSMQ 操作的完整性，我在我的 RESTFull 和 MSMQ 之间插入了一个事务性 WCF 服务，并且在 MSMQ 上使用了触发器，它又具有策略驱动的事务性数据处理。请注意，MSMQ 触发器需要安装 MSMQ 触发器功能。我选择了基于 exe 的触发器，因为替代方法是使用基于 COM 的 DLL，我不喜欢使用 COM，因为自由线程 DLL 需要实现复杂的 C++ 应用程序和单元线程，这在 C# 中使用 CCW 设计相对容易，对应用规模施加限制。最后 RESTFull 调用可以被认为是“接近事务的”，因为它是在事务的上下文中执行的，除非你有一些严重的错误，例如错过捕获错误条件（基本上错过实现 try / catch ）并抛出，当需要提高错误条件时，您将受益于可靠的提交/回滚。然而，当丢失数据被认为等于没有提交时，通过检查调用和合理的超时来加强，以确保消息传递的可靠性，这是很好的。