Merge Replication-Apply BCP files

How can i apply a BCP files generate by Distributor in the Suscribers.

I don′t know wich parameters BCP.EXE need.

Thanks

Can you explain why you need to manually apply them? Is the merge agent not applying them for you?|||

I need to manually apply because there is few information, and i've configured suscription with the option to no send the schema tables.

I've configured the replication via internet (is slow for a very large tables)

But now i need to send data to the suscribers.

Thanks

|||

manually applying the bcp files is not recommended. If you're having problems, then let us know what they so we can walk you through a solution.

What part is slow, applying the snapshot to the subscribers? Are these large tables? Are you using filtering, and using the dynamic snapshots? Is the agent failing? How would bcp'ing the data across the internet be any faster than merge agent applying the snapshot?

|||

I only need to know how can apply manually the BCP files on the susbcribers.

Any body knows what parameters i have to use to do this.

Thanks

|||I thinks I am having same requirements like Jorge,

See What I am looking for is quit similar to Jorge's case,

I have 2 Database Servers, I have set Merge Replication (Pull) between them,

But Sometimes The Connectivity between both of them is not available for many days, still data needs to be transfered through CD.

I thinks this problem is relavant, if not pls ignor, and pls give some solution

Merge Replication updating SP3 to SP4

Gurus,
I am planning to update SP3 to SP4 on a replicated server.
A- Please correct me if i wrong in order.
1- Apply SP4 on Publisher / Distributor (on single box)
2- All subscribers.
B- As per my knowledge there are no issues while applying SP4. Is there any
known issue while applying the sp4 has to be taken care of?
TIA
Regards
Javed Iqbal
Javed,
I agree with the order. I've had a search of this newsgroup (using Google
Groups) to check for sp4 and there are hardly any reported errors so far.
The main on e is
http://groups.google.com/group/micro...85 a5a37097d4
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Merge Replication does not apply changes in original order!

Has anyone noticed that Merge Replication does not apply changes in original
order?
This causes foreign keys errors but I fixed that by making the foreign keys
'not for replication'.
It also causes unique index errors if I am manipulating the unique values in
an exact sequence - anyone have a solution to this one?
That's correct!
I'm not exactly sure what order it will apply the changes in however. But
what it does is gathers up the changes, figures out what to apply where, and
then applies it one by one. If there is a pk/fk/GodKnowsWhat violation in
the initial attempt, the modification goes into a queue and when the merge
agent has completed the initial pass, it will retry the failures another
time.
For the majority of the cases, this second (or third, forth, etc) retry will
succeed. Sometimes you need to bump up the generationsperbatch switches to
2000 for this to succeed.
Merge replication in SQL 2005 will apply changes which belong to related
tables together in the same batch boundary so you don't have to worry about
this anymore.
Also becareful that you don't enforce cascading updates and deletes for
replication as this can get you into trouble.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jim Breffni" <Jim Breffni@.discussions.microsoft.com> wrote in message
news:F55EE9FB-7733-4EDD-8E2B-A439978D3924@.microsoft.com...
> Has anyone noticed that Merge Replication does not apply changes in
original
> order?
> This causes foreign keys errors but I fixed that by making the foreign
keys
> 'not for replication'.
> It also causes unique index errors if I am manipulating the unique values
in
> an exact sequence - anyone have a solution to this one?
|||Thanks Hilary - where do I set the checkSortOrder generationsperbatch switch?
Jim.
"Hilary Cotter" wrote:

> That's correct!
> I'm not exactly sure what order it will apply the changes in however. But
> what it does is gathers up the changes, figures out what to apply where, and
> then applies it one by one. If there is a pk/fk/GodKnowsWhat violation in
> the initial attempt, the modification goes into a queue and when the merge
> agent has completed the initial pass, it will retry the failures another
> time.
> For the majority of the cases, this second (or third, forth, etc) retry will
> succeed. Sometimes you need to bump up the generationsperbatch switches to
> 2000 for this to succeed.
> Merge replication in SQL 2005 will apply changes which belong to related
> tables together in the same batch boundary so you don't have to worry about
> this anymore.
> Also becareful that you don't enforce cascading updates and deletes for
> replication as this can get you into trouble.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "Jim Breffni" <Jim Breffni@.discussions.microsoft.com> wrote in message
> news:F55EE9FB-7733-4EDD-8E2B-A439978D3924@.microsoft.com...
> original
> keys
> in
>
>
|||you don't. What you do is make the generationsperbatch switches very large
in hopes that the pk fk modifications will occur in the same batch.
You should set
MaxDownloadChanges
MaxUploadChanges
UploadGenerationsPerBatch
DownloadGenerationsPerBatch
UploadReadChangesPerBatch
DownloadReadChangesPerBatch
UploadWriteChangesPerBatch
DownloadWriteChangesPerBatch
to 2000


Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jim Breffni" <JimBreffni@.discussions.microsoft.com> wrote in message
news:BD122CA6-5721-428B-8F1E-791E99CE1E72@.microsoft.com...
> Thanks Hilary - where do I set the checkSortOrder generationsperbatch
switch?[vbcol=seagreen]
>
> Jim.
>
> "Hilary Cotter" wrote:
But[vbcol=seagreen]
and[vbcol=seagreen]
in[vbcol=seagreen]
merge[vbcol=seagreen]
will[vbcol=seagreen]
to[vbcol=seagreen]
about[vbcol=seagreen]
values[vbcol=seagreen]

Merge Replication after data moved to a new server.

We need to move a database to a new server that is the main replication server.
The process was to build a new clean server and apply all patches and updates.
Replicate with all servers, then backup the database. Restore this database
to the new server. create a new subscription. All seemed to work except now
only new records created are replicating and any updates to existing records
are not updating. Any Ideas ?.
Conrad,
I'm a little unclear as to what you actually did. Did you have an existing
publication and then move this to a new server? Did the server have the same
name? Did you restore the msdb and distribution databases also? What type of
replication was this?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Envoriment is the following.
Server A publication database
Server B Remote Server
Server C Remote Server
Server A using push subscription to server B & C.
Server D new server.
Process:
Allow agents to sync with Server B & C so all databases are in sync.
Backup Server A Publication Database.
Disable Server A subscriptions. (disable server subscription agents)
Restore Server A Publication Database to Server D ( Different Name )
Create new publication for Server D
Create new push subscriptions to Server B & C
All subscriptions are merge subscriptions only.
When data is changed on server B & C some data was merged ( as new data was
modified or added ) and some create replication errors where the agents
believe that the data was changed outside of replication. ( I beleive the
metadata on Server B & C did not believe the system was in sync and was
trying to update the new publication server while it believes the data was
changed on server A publication and not applied yet )
When I restored the publication database to Server D ( Differenet Server
Name) the metadata is cleared by design ( This was done to make sure metadata
was clean. I assumed because the data was in sync that the remote server B &
C also believed the data is in sync ).
Is there a way to clear all metadata of the remote servers replication
history ?
I was hoping that this process would re-create the initial install of the
databases which worked great for a long time.
"Paul Ibison" wrote:

> Conrad,
> I'm a little unclear as to what you actually did. Did you have an existing
> publication and then move this to a new server? Did the server have the same
> name? Did you restore the msdb and distribution databases also? What type of
> replication was this?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Conrad,
probably needa little more info about the topology - eg why is Server D set
up as another publisher?
Does it publish the same articles or different ones?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Server D is a new faster server replacing Server A
Server A will then become the test server for future application testing in
a replicated env. This is why Server D is using a different Name. Server A
will remain as is but witha role in the test env.
So the production setup is
Server D Publication Server using push subcription to Server B & Server C
Where the data changes are on Server B & C. There are no data changes on
Server D. and backup of the data is on Server D ( Central data center )
"Paul Ibison" wrote:

> Conrad,
> probably needa little more info about the topology - eg why is Server D set
> up as another publisher?
> Does it publish the same articles or different ones?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
>
|||Conrad,
whenm doing this, I'd synchronize the A publisher with B and C. Restore A on
D then remove the replication setup (after scripting it all out). Then I'd
set up D as the publisher and do a nosync nitialization to B and C. AFAIK,
if you try to move replication in situ to differently named servers this is
not supported as the servername is hardcoded into too many meta data tables.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||The step of
do a nosync intialization to B and C. not sure what you mean by this step.?
I setup a subscription where the the data and schema are not used is this
what you mean.
"Paul Ibison" wrote:

> Conrad,
> whenm doing this, I'd synchronize the A publisher with B and C. Restore A on
> D then remove the replication setup (after scripting it all out). Then I'd
> set up D as the publisher and do a nosync nitialization to B and C. AFAIK,
> if you try to move replication in situ to differently named servers this is
> not supported as the servername is hardcoded into too many meta data tables.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||I think we're talking about the same thing. It's the option in the wizard
where you select to Not initialize the data because the subscriber already
has it.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)