sdcharle's questions

我们有一个合并出版物，它在很长一段时间（几年）内大部分时间都可以正常工作。最近添加了一篇文章，我们被告知快照已过期，因此我们重新生成了它。然后我们在初始化期间收到错误消息，并在详细的错误日志中发现了这个问题：

消息 1934，级别 16，状态 1，过程 DDLTrigger_Index，第 19 行插入失败，因为以下 SET 选项的设置不正确：“ANSI_PADDING”。验证 SET 选项是否适用于索引视图和/或计算列上的索引和/或查询通知和/或 xml 数据类型方法。

...快进到现在。在实验中，我们发现是的，可以在发布者上创建合并发布并在我们的订阅者服务器上订阅，但前提是使用不同的数据库。通过这个只是为了排除权限/等，并确定问题确实是订阅者数据库。

因此，从受影响的数据库中删除复制以清除任何隐藏的元数据混乱似乎是合乎逻辑的：

sp_removedbreplication @dbname = 'sickDB' @type = 'all'

到目前为止，一切都很好。但是现在，我得到了完全相同的错误，但在此过程中要早得多。具体来说，执行时：

/****** Begin: Script to be run at Subscriber ******/
use [sickDB]
exec sp_addmergepullsubscription 
@publisher = N'publisher',
 @publication = N'publication', 
 @publisher_db = N'goodDB',
  @subscriber_type = N'Local',
   @subscription_priority = 0,
    @description = N'hope this works', @sync_type = N'Automatic'

（上面略有编辑）。

元数据中是否还有一些剩余的问题？关于 ANSI_PADDING 东西的原始理论实际上是订户数据库中有一些带有计算列的表，因此这似乎是相关的。然而，ANSI_PADDING 设置（和谷歌搜索）的一些翻转并没有真正得出结论性的答案。

非常感谢您的阅读，并让我知道我可以提供的任何其他可能有帮助的信息。

哦，是的，发布者和订阅者都是 SQL Server 2005。

我正在 2 台服务器 A 和 B 之间建立 Service Broker 通信，我们将调用它们。我以这篇文章为例。

A 是 SQL 2005，B 是 SQL 2012。它不起作用，而且我无法找到一个很好的原因。我能看到的是：

接收端的 Profiler 甚至不显示任何 Service Broker 事件，这表明没有任何东西可以访问它。

但是使用 ssbdiagnose 如下，它表示恭喜，您没有错误：

C:\Users\me>ssbdiagnose -level info -E configuration from service ServerAServiceTest -S ServerA -d MyDB to Service ServerBServiceTest -S ServerB -d MyDB on Contract myContract

Microsoft SQL Server 11.0.2100.60
Service Broker Diagnostic Utility
0 Errors, 0 Warnings

同样在传输队列中，我看到的唯一看起来特别不正常的是“to_broker_instance”为空，尽管我在设置路由时明确指定了该信息。

此外，transmission_status 中没有显示任何错误。

此外，SQL Server 错误日志没有任何意义。

至于防火墙问题，嗯，这些是无法从外部访问的测试服务器，所以我尝试完全关闭防火墙。

一件麻烦的事情，我会得到这些：

在目标队列中排队消息时发生异常。错误：15581 状态：7. 请在数据库中创建主密钥或在会话中打开主密钥，然后再执行此操作。

我打开钥匙，这些就消失了。但是我不应该每次想要做某事时都必须反复打开钥匙，不是吗？我怀疑这是问题的一部分，即使如上所述错误消失了。

很抱歉这个有点悬而未决的问题 - 即使是一些帮助确定从哪里获得更多信息错误或调试信息也会很棒。这对我来说是新的领域。