C# SQL Server触发器-将消息发送到队列

SQL Server 2005中的CLR触发器是否可以通过MSMQ向队列发送消息

我正在使用SQL Server项目类型，但System.Messaging不会显示为我可以添加的引用

---

基本上，当一行被写到表中时，我需要某种类型的操作来执行（打印）。生成行的设备是一个手持式扫描仪，它只能执行基本操作——其中之一就是通过odbc向SQL server写入数据。最初的想法是轮询表，抓取记录，打印记录，删除记录。这可能很好，但它似乎是了解消息队列的一个很好的案例和借口。

这可能适合您：

是的，这是可能的

不过，我不会在一个触发器中这样做：TXN将保持更长的开放时间，它是资源密集型的，如果它挂起怎么办等等

您可以通过存储过程进行更新吗

---

或者将一行推送到由写入队列的SQL代理作业监视的轮询表中？

如果该程序集不受信任，您仍然可以从SQL Server访问它-它只是在本机上不可用，必须手动导入并将其本身标记为“不受信任”。不久前，我在System.DirectoryServices中遇到了同样的问题

这家伙在System.DirectoryServices方面与您有相同的问题，但以相同的方式执行CREATE ASSEMBLY语句应允许您访问系统。消息传递：

---

以下是一些关于如何处理这一老问题的新想法：

---

Nginn messagebus是我基于SQL server的消息队列项目，面向依赖SQL server的.Net应用程序。

通过推送技术进行事务处理很难

这样做的唯一事务性选项是使用WCF桥接器，它要求反过来使用SQL Server 2008，自2012年以来，动态后台编译SQL Server托管的CLR阻止的基于WSDL的程序集，我从未破解过如何强制编译这些程序集，以避免引用托管CLR策略禁止的程序集

我发现唯一可行的选择（可能是因为我没有找到解决方法）是使用HttpClient RESTFull风格的网络客户端，其中包含在sqlserver代理激活过程之外的CLR集成过程。它工作得非常好，只有一个问题，RESTFull不支持开箱即用的事务性。因此，如果您需要有保证的消息传递，您需要在消息流的某个地方进行检查调用

---

事实上，为了保护MSMQ操作的完整性，我在RESTFull和MSMQ之间插入了一个事务性WCF服务，并在MSMQ上使用了触发器，这反过来又具有策略驱动的事务性数据处理。请注意，MSMQ触发器需要安装MSMQ触发器功能。我选择了基于EXE的触发器，因为它的替代方法是使用基于COM的DLL，而我不喜欢使用COM，因为自由线程DLL需要实现复杂的C++应用，而在线程中用CW设计的相对简单的BooLoad线程限制了应用程序的规模。最后，RESTFull调用可以被认为是“接近事务性的”，因为它是在事务上下文中执行的，除非您有一些严重错误，例如在需要提出错误条件时，遗漏以捕获错误条件（基本上遗漏以实现try/catch）和抛出，您将受益于可靠的提交/回滚。然而，当丢失数据被认为等于没有提交时，使用检查调用和合理的超时来加强，以确保消息传递的可靠性，这很好。

我认为存储过程是可行的，但我仍然不确定访问系统的障碍。来自SQL Server项目的消息传递。我在谷歌上搜索这条消息，得到的是混合信号——系统。消息不可信，所以SQL Server无法使用它，或者这是错误的？对不起，我自己没有使用过。您看过ServiceBroker吗，它是SQLServer2005的一部分？我已经简要地读过了。我对这一点完全不了解，但似乎Service Broker会让触发器将消息添加到Service Broker队列，但我的程序将不得不轮询该队列，此时我也可以轮询该表。Service Broker+SqlDependency似乎需要进一步探索。同时，我只需轮询表中的添加项，并在处理完后将其删除，就可以让它正常工作。简单易用，但我的信息还需要抓挠：）