false. And, yes, the conflicts are dropped from one merge to the next, but
the subscription is active for 14 days. Very strange behavior that I've not
been able to track down the cause of...
"Hilary Cotter" wrote:
> Can you modify your publication to set compensate_for_errors to be false?
> This will prevent the errors from being wiped out.
>
> It is troubling that they are not being retained? Conflict tables are purged
> after the retention period has past. I take it that this is not the case.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
>
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
>
> Looking for a SQL Server replication book?
>
http://www.nwsu.com/0974973602.html >
> Looking for a FAQ on Indexing Services/SQL FTS
>
http://www.indexserverfaq.com >
>
>
> "J Jones" <JJones@discussions.microsoft.com> wrote in message
> news:2FF4706D-A352-4B89-8EA1-E2B63F0E24C0@microsoft.com...
> >I have a few subscribers that are complaining of dropped data in one of the
> > main tables that users update on the subscriber machines. When they
> > replicate, the agent history indicates there were conflicts, but when I go
> > to
> > the conflict viewer, no conflicts show up.
> >
> > The dropped data does not occur when users hit the application via the
> > publisher database, which leads me to believe it's not an app problem but
> > indeed a replication issue. However, with no conflicts in the conflict
> > viewer, but conflicts shown in the agent history, I'm unable to
> > troubleshoot
> > this problem.
> >
> > Any help is greatly appreciated!
> > Thanks!
> > Jeff Jones
> > Atlanta, GA
>
>