2

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

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Morrislgn
  • 3,717
  • 4
  • 24
  • 26
  • We are having the exact same issue. In one instance, we were able to resolve it by removing the offending foreign key and trying to get by without enforcing referential integrity. I have offered a bounty on this question as there is very little information anywhere regarding this issue. A similar issue has recently been posted on Microsoft connect with no resolution: http://connect.microsoft.com/SQLServer/feedback/details/668349/sql-ce-web-sync-pull-subscription-fails-to-initialize-with-value-violated-the-integrity-constraints-for-a-column-or-table-on-32-bit-platform-but-succeeds-on-64-bit – Evil Pigeon Jul 21 '11 at 09:50

3 Answers3

2

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.

Morrislgn
  • 3,717
  • 4
  • 24
  • 26
1

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.

Ben Thul
  • 31,080
  • 4
  • 45
  • 68
  • We tried this but didnt get much which we were able to sense of. Based on the info we have got from the device gives us the row guid and table, but we cant track it further than that. – Morrislgn Feb 10 '11 at 15:52
  • If yuo know the row that is causing the problem then you have nearly solved the problem. The record will be most likely be an orphan, check to make sure that all foreign key constraints are satisfied and that the parent has not been deleted. – Moog Jul 28 '11 at 21:38
0

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.

SPE109
  • 2,911
  • 1
  • 19
  • 16