"Jim Breffni" <JimBreffni@discussions.microsoft.com> wrote in message
news:C3E8DA76-F717-4353-8E0B-FACDA058F3DB@microsoft.com...
> Should this situation happen again I suggest:
>
> 1. Prevent further updates on remote stations until replication is
re-setup
> OR choose a time for the resync that least interferes with operations -
the
> longer you leave it the worse your problem becomes
> 2. Remove publication(s) and subscriptions
> 3. Use a tool like Red Gates "Data Compare" to see what data the
publisher
> is missing - it will generate the sql inserts for you, this sql may need
to
> be manually tweaked
> 4. Apply update scripts
> 5. Recreate publication(s) and subscriptions
> 6. Find the person who caused the problem and apply thumbscrews
>
>
> Jim.
>
>
>
> "WB" wrote:
>
> > I have one corporate server that acts as both publisher and distributor.
> > Remote locations all have SQL server loaded and act as subscribers.
This
> > setup has worked great until yesterday. Somehow, and it is still under
> > investigation, the corporate server "lost" all subscriptions and became
> > disconnected from the remote locations.
> >
> > Each location is on a 5 minute schedule for the merge agent to run.
> >
> > After recreating all the subscriptions and "pushing" them down to the
remote
> > locations, there has been information lost during the down time. The
> > snapshot agent had to be run in order to recreate the subscriptions. I
am
> > trying to figure out how I could have reconfigured the setup so that
when
> > the subscription was made all the data in the remote locations would
have
> > been preserved and "Merged" with the data from the server.
> >
> > Thank you in advance for you input.
> >
> > WB
> >
> >
> >