A conflict issue, or something else...?

Tony,
are these changes made at different subscribers? If so,
then the last subscriber to synchronize will win. Perhaps
you need the 'Later Wins' resolver based on eg
a 'dateedited' column.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Paul,
Thanks for your suggestion.
The records concerned are filtered and only visible at the publissher and
one subscriber.
For now I've kludged the application at the subscribers to overwrite any
spurious changes but I'd like to understand whats happening.
Initially my thoughts were that an application at the publisher may be
rewriting whole rows rather than individual fields, so if a field 'name' was
to be updated the query was
update PRecs set check=X, name=Y where PRef=N
rather than
update Precs set name=Y where PRef=N
(it's difficult to tell as the app uses data aware controls and wasn't
written by us)
In any case I would have thought 'Subscriber Wins' would take care of things
in this situation. I'll try your later 'Later Wins' suggestion but I'd
love to understand what's going on. Some horrible performance issue perhaps,
maybe due to record changes while merge is in progress?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:0c8801c4cb23$c1fe9f40$a501280a@.phx.gbl...
> Tony,
> are these changes made at different subscribers? If so,
> then the last subscriber to synchronize will win. Perhaps
> you need the 'Later Wins' resolver based on eg
> a 'dateedited' column.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Tony,
'Treat changes to the same column as a conflict is selected' shouldn't make
any difference as it appears as though you don't have a conflict. However
you do have filters. If the record change violates the filter, it'll get
overwritten. If this is not the case I can't see how this is possible
Merge has no sense of the interim values - just the guid of the changes row
is of relevance, so the latest value at the time of running the merge agent
is used. Have you checked the conflict table just in case?
I'd guess it's either a filter issue or a conflict, although with your
selected resolver and one subscriber it's difficult to see.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)