Hilary Cotter wrote:
> unfortunately there is no way other than a resync.
>
> --
> 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
>
>
>
> "paulysc" <paulysc@optonline.net> wrote in message
> news:1142873309.302369.132900@e56g2000cwe.googlegroups.com...
> >I set up merge replication but never change all the foreign key
> > constraints to have the "Not for replication" attribute, we had
> > this up and running for a couple of weeks prior to finding out that the
> > foreign key constraint would fire during the replication process at
> > times when it seemed to do the inserts in a illogical order (child data
> > prior to the parent data) the end result was the sync process would
> > delete some child data. I was able to recover some data from the
> > conflict resolve but I need to know is there a way I can recover more
> > then the couple of days that was stored in the conflict tables?
> > Anybody have any suggestions. I also dropped every foreign key
> > constraint and trigger in the system and added back with the "Not for
> > replication" attribute, going forward my data loss issue has been
> > resolved.
> >