SQL Server 2005 复制完整性违规 SQL Server，错误号：28549
我希望有人能帮助我解决一个非常奇怪的问题。
当用户同步其设备时，他们会收到此错误：
行操作无法重新应用 由于诚信违规。查看 出版物过滤器。 [表= 资产详细信息，操作 = 插入/更新，RowGuid = {C92038E4-18EA-EE11-4C9F-2952CDECFCC7} ] HRESULT 0x80040E2F (28549)
当我们转到服务器并查询该行及其父行（表称为资产）时，它似乎是有效且正确的。当我们探索完整的过滤器树时（为了更好的描述），所有数据似乎都是正确的。
从我们在数据库中可以看到，应该发送给订阅者的数据遵守数据库中的引用完整性约束。它还遵守发布过滤器。
我们是否有理由在订户身上遇到此问题？我们该如何解决这个问题？
另外，是否可以准确记录发送到设备的数据 - 如果不是数据，则针对 sdf 文件运行语句以识别发生的情况？
预先感谢您的帮助，
Morrislgn
I am hoping someone can help me with a really bizarre problem.
When users sync their device they are getting this error:
The row operation cannot be reapplied
due to an integrity violation. Check
the Publication filter. [ Table =
ASSET_DETAIL,Operation =
Insert/Update,RowGuid =
{C92038E4-18EA-EE11-4C9F-2952CDECFCC7}
] HRESULT 0x80040E2F (28549)
When we go to the server and query this row and its parent row (table is called Asset) appears to be valid and correct. When we explore the full filter tree (for want of a better description) all the data appears to be correct.
From what we can see in our DB the data which should be going to the subscriber obeys the referential integrity constraints in place in your DB. It also obeys the publication filter too.
Is there a reason why we would getting this problem on the subscriber? And how can we resolve this?
Also, is it possible to log exactly what data is being sent to device - if not data, the statements being run against the sdf file to identify how is happening?
Thanks in advance for your help,
Morrislgn
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不确定这在技术上是否是一个答案，但它是我们遇到的问题的答案。
我们发现一位同事删除了我们数据库中的 FK 关系，但没有告诉任何人。因此，当我们查看数据库和数据时，一切正常。
只有当我们将架构与测试版本进行比较时，我们才意识到发生了什么。
因此，本例中的答案是使用单独的数据库验证架构。
Not sure if this is technically an answer, but it is the answer to the problem we were having.
We discovered that a colleague had deleted a FK relationship in our DB and neglected to tell anyone about it. So when we were looking at the DB and the data everything was ok.
It was only when we compared the schema to our test version that we realised what had happened.
So, the answer in this case was to verify the schema with a separate DB.
命令通常通过存储过程应用于订阅者。当订阅者重新连接时运行分析器以查看正在运行的内容以及参数。这可能会给您提供有关正在发生的事情的线索。不幸的是，我不能更具体。
Commands are typically applied at the subscriber through stored procedures. Run a profiler when your subscriber reconnects to see what's running and with what parameters. That might give you a clue as to what's happening. I can't be more specific, unfortunately.
这与在您的约束上使用“不用于复制”条款有什么关系吗？请参阅 http://msdn.microsoft.com/en-us/library/ms180843。 aspx 或 http://msdn.microsoft.com/en-us /library/ms152529.aspx
因此，当使用复制（例如 OrderHeaders 和 OrderLines）时，复制可能会在您的订阅者中的 Orderheader 记录之前插入 OrderLines，然后您会遇到违规。
指定“Not For Replication”意味着当通过复制系统插入行时不会对约束进行检查，因为它们已经在发布者处进行了检查。
Has it got anything to do with using the 'Not For Replication' Clause on your constraint. See http://msdn.microsoft.com/en-us/library/ms180843.aspx or http://msdn.microsoft.com/en-us/library/ms152529.aspx
So when using replication say of OrderHeaders and OrderLines, the replication may insert the OrderLines in your subscriber before the Orderheader record and then you get the violation.
Specifying Not For Replication means that the checks on constraints are not made when the rows are inserted via the replication system as they have already been made at the publisher.