Conflict Table - What does this error mean? Does the Conflict get cleared ?

I have two publications set up on my db, one for ordinary users that
employs horizontal/vertical filters, the other for admins with no
filters. I noticed over a period of time records going missing and when
I checked my conflict tables I received the following:
"The same column(s) of the same row was updated at both 'ServerA' and
'user - -129404259'. The resolver chose the update from 'ServerA' as
the winner."
1. Can someone explain what exactly this means and how I can avoid it?
The MS explaination of "Changes are made to the same column(s) in the
same row (using INSERT, UPDATE or DELETE statements) in more than one
copy, with column-level conflict tracking in effect." isn't that clear
to me.
2. Do the Conflict Tables every get cleared. For example, if I had an
issue 1 month ago and didn't check my conflict tables is there any
chance they could have been cleared. Reason I'm asking is that I have
records which went missing over a couple of months back and there's no
record in the conflicts table.
Thanks.
Hello Ciaran,
To understand the meaning of the error message, you need to understand how
Merge Replication works. Please read the following topic:
How Merge Replication Works
http://msdn.microsoft.com/library/de...us/replsql/rep
ltypes_30z7.asp
Please also refer to the "Microsoft Replication Conflict Viewer, Merge
Publication" topic and "Microsoft Replication Conflict Viewer, Updatable
Subscriptions" topic in SQL books online(BOL)
Update conflict happens when the same data is changed at two locations. The
message means Update conflict happened. Conflicts are automatically
resolved using the conflict resolver initially selected when the article
was created. As conflicts are resolved during synchronization, the data
from the losing row is written to a conflict table. The Replication
Conflict Viewer allows you to review these conflict records and,
potentially, modify your data.
When you resolve a conflict using Replication Conflict Viewer, you can
choose to accept the original resolution or submit an update to the data
based on the winning or losing row. In each instance, the logged conflict
row is deleted from the conflict table. Thereafter, you should periodically
review conflicts to help reduce the size of the conflict tracking tables.
When creating a new merge publication using sp_addmergepublication, you can
specify the conflict retention period using @.conflict_retention parameter.
Please refer to the following information in the sp_addmergepublication
topic in BOL:
[@.conflict_retention = ] conflict_retention
Specifies the retention period, in days, for which conflicts are retained.
conflict_retention is int, with a default of 14 days before the conflict
row is purged from the conflict table.
That is, by default, the conflict retention period is 14 days. The conflict
row is purged from the conflict table after 14 days.
I hope above information is helpful.
Sophie Guo
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Thanks for the reply Sophie, this explains why the conflict table was
being cleared.
Regarding the conflict happening I still can't understand why this is
happening or more importantly what I can do to fix it. I do have an
INSTEAD OF UPDATE/INSERT Trigger on the table I'm syncing with and my
only guess is that this is causing the conflict to occur.
Any ideas on what type of issues can cause this conflict or a pointer
to some samples
is much appreciated.
|||Hello Ciaran,
What replication did you create? Are both sides trying to update the same
table when the conflict occurs? If both 'ServerA' and 'user - -129404259'
try to update the same table at the same time, this behavior is normal.
If the issue occurs although there are no updates on both sides, to isolate
the issue, I recommend you perform the following steps:
1. Create a new test database.
2. Create the related tables in the new database and insert some data into
it.
3. Create a new replication locally and check if you can reproduce the
issue.
If you can reproduce the issue, please post here the detailed steps and the
related data. I will check if I can reproduce the issue on my side.
Please know that replication issues tend to be very complex and hard to
troubleshoot in newsgroups. If you need further assistance, I recommend
that you open a Support incident with Microsoft Customer Service and
Support (CSS) so that a dedicated Support Professional can work with you in
a more timely and efficient manner. If you need any help in this regard,
please let me know.
For a complete list of Microsoft Product Support Services phone numbers,
please go to the following address on the World Wide Web:
<http://support.microsoft.com/directory/overview.asp>
If you are outside the US please see http://support.microsoft.com for
regional support phone numbers.
If anything is unclear, get in touch.
Sophie Guo
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.