我们正在开发将使用服务代理从一个数据库的消息传送到其他的应用程序。 SOURCEDB是通过从其中我们吸掉一些数据的现有应用程序所使用。 TargetDB由该应用程序只使用和处理/分发我们需要的数据。 我们只使用一种类型的合同和双方的DB在同一台服务器上。
我们建立了相同的消息类型，对双方的合同，以及各自的启动器和目标队列/服务。 在这两个数据库：
-
ENABLE_BROKER设置 -
TRUSTWORTHY设置 - 有一个独特的
service_broker_guid - 有
sa如数据库所有者，与所有SSB授权语句是dbo或OWNER适当。
然而，当我们从SOURCEDB发送一条消息：
BEGIN DIALOG CONVERSATION @dialogHandle
FROM SERVICE [//Service/Initiator]
TO SERVICE N'//Service/Target'
ON CONTRACT [//Contract/Notification]
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @dialogHandle
MESSAGE TYPE [//Message/Notification] (@RequestMsg);
...消息没有找到自己的方式存在。 进一步的调查揭示了如下结果：
- 引发剂队列为空
- 目标队列为空（注：不需要到的问题
RECEIVE） - 发送队列是空
- 没有错误记录，无论是在SQL Server日志或在我们的CATCH错误在创建该消息的存储过程处理
- 在SOURCEDB的发起方队列的条目
sys.dm_broker_queue_monitors如果允许激活被设定为作出通知 - SOURCEDB的
sys.conversation_endpoints有一个新的条目CONVERSING状态 - 在TargetDB的目标队列的条目
sys.dm_broker_queue_monitors如果允许激活保持无效 - TargetDB的
sys.conversation_endpoints有一个新的条目CONVERSING状态同样conversation_id和不同conversation_handle从SOURCEDB的入口
虽然测试数据库是SQL 2005（应用程序必须支持2005年），我跑从我的开发机器的2008安装ssbdiagnose实用程序dianose问题：
ssbdiagnose -S testserver -d SourceDB CONFIGURATION FROM SERVICE //Service/Initiator TO SERVICE //Service/Target ON CONTRACT //Contract/Notification
这产生了以下：
D 29912 dbtestsvr SourceDB Service //Service/Target was not found
D 29975 dbtestsvr SourceDB User dbo does not have SEND permission on service //Service/Target
这是令人困惑，因为dbo不应该被剥夺任何权限， //Service/Target肯定是存在的，尽管在不同的数据库。 但我的同事跑了探查器跟踪这表明正在执行寻找一个命令//Service/Target上SOURCEDB。 服务经纪人似乎得到某种方式混淆。 添加一个明确的路线，除了是理论上不必要的，不改变这种状况。
我跑了几乎相同的一套教程命令我们的测试服务器上，一切工作正常，所以它可能是一些DB-具体。
我们的设置是工作，前两天，所以我们可能寻找可能已经得到改变一些设置，但没有运气。
