Re: The process could not deliver the snapshot to the Subscriber
From: Paul Ibison (Paul.Ibison_at_Pygmalion.Com)
Date: Sun, 15 Aug 2004 13:17:51 +0100
if you are on the subscriber, can you successfully access the repldata share
and open the MSmerge_contents.bcp and MSmerge_contents.sch files? It looks
to me that the snapshot files don't exist - perhaps they have been cleaned
up, or the snapshot agent not run. Even on a nosync initialization, for the
metadata tables these files are still necessary.
"Sam" <email@example.com> wrote in message
> I'm trying to accomplish what is in the following article:
> After restoring a publisher database, starting a merge-agent results in
> The job failed. The Job was invoked by User sa. The last step to run was
> step 1 (Run agent.).The process could not deliver the snapshot to the
> Subscriber. The step failed.
> Source: ODBC SQL Server Driver
> Number: 0
> Message: Unable to open BCP host data-file
> Source: MIKELAPTOP
> Number: 20037
> Message: The process could not bulk copy into table
> The subscription has been marked for reinitialization. Reinitialization
> occur the next time you synchronize this subscription.
> Does the size of the database (1.05 gb) have anything to do with the last
> error "The subscription has been marked for reinitialization...."
> I'm attempting to do the following for a merge pull subscription. I just
> read the following that there is a nosynch option on merge publications.
> this is true then how do I move a large subscription without using copy
> The msf file that is generated is greather than 2gb so there is a
> in windows os to 2gb.
> Merge Replication
> Note No-synch subscriptions are not supported for merge pull
> When you use backup or restore to set up a subscription to a merge
> publication with the no-sync option, follow these steps:
> 1.. Publish the database, and then run the Snapshot Agent. If the
> has been published, you only have to run the Snapshot Agent.
> All changes that are made on the publisher are now recorded in the merge
> replication system tables.
> 2.. Back up the published database, and then restore it on the
> 3.. Create a new subscription, and then select No, the Subscriber
> has the schema and data.
> 4.. Run the Merge Agent.
> When the Merge Agent runs, it first uses the snapshot to create the
> replication tables. All the changes that were made since the snapshot was
> generated are applied to the subscriber:
> a.. If you added any rows between step 1 and step 2 in this procedure,
> you will see the new rows as updates on the subscriber. The rows already
> exist because of the restore. Therefore, you will see the new rows on the
> b.. If you deleted any rows between step 1 and step 2 in this
> the Merge Agent reports that no changes must be made because the rows do
> exist on the subscriber. The backup or restore was performed after the
> were deleted on the publisher.
> c.. If any rows were updated between step 1 and step 2 in this
> procedure, you will see these as updates on the subscriber.