Merge Replication Problem

Hello
I have merge Replication MSSQL Server 2000 SP4, One Publisher and 5
subscribers,
a) Subscribers1 has inserted the record at 8 AM and Send it to
subscribers2 & subscribers3
b) Using DTS, but not insert directly subscribers2 DB its Inserted
TempDB to subscribers2 DB using Store procedure.
c) Subscribers2 users update same records at 3 PM. It means now other
Subscribers not update those records.
d) I changed my article
@.property='compensate_for_errors',@.value='false'.
e) I have facing some conflict Problems
f) After Synchronization those records was deleted at some
Subscriber
g) We are Synchronization at 1 AM. For Schedule bases
Here the Question.
Why the Data going to deleted?
Which data going to Synchronies in above case?
Suppose I update row 1 following time
Subscribers1 at 6 am
Subscribers1 at 7 am
Subscribers1 at 8 am
Subscribers1 at 9 am
Subscribers1 at 11 am
Which data going to Synchronies in above case?
Please Explaning Clearly
Thanks
Sam
Sam I am having problems understanding the scenario you present. Before I
start guessing at what happened I want to explain a couple of things.
a) compensate_for_errors - this switch means that if a conflict occurs the
data will not be wiped out on the conflict loser. For example if a row with
the same PK value is simultaneously inserted on the publisher and subscriber
and the compensate_for_errors switch is set to true (true is default for SQL
2000, false is the default for SQL 2005) the row on the subscriber will be
deleted and replaced with the row from the publisher. If the
compensate_for_errors setting is set to false, the row on the subscriber
will not be deleted - in other words - the subscribers row will remain.
With this setting all such compensating actions will not occur.
b) when you use DTS with the defaults the rows dts'd into the table are not
logged and will not be replicated. Consult
http://support.microsoft.com/kb/275680/en-us for more information.
c) exactly what do you mean by "Using DTS, but not insert directly
subscribers2 DB its Inserted TempDB to subscribers2 DB using Store
procedure." If you mean it was DTS'd to tempdb and then from tempdb to the
subscriber2 db, this should have been logged and any inserts or other DML as
a result of this action should be replicated.
d) did you run conflict viewer for a window into what is happening?
It sounds like what happened what that in step b the rows were not logged
and hence never made it to subscriber 1 and subscriber 3. I don't understand
what happened in f). The conflict viewer should have a record of what
happened.
To answer your questions - data should not be deleted with the
compensate_for_errors setting set to false - only true.
From what you describe in the below scenario, if you are updating the same
row the update should flow with each synchronization unless you are doing
column level tracking - this would be logged as a conflict and the conflict
winner should win the conflict - ie its data should make it to all the
subscribers.
If the sync doesn't happen each hour, only the final result will travel. For
example if the sync runs at 11 am, only the final 11 am change will move.
HTH
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
"Sam" <shankar@.cdscom.co.th> wrote in message
news:Os7L2bEOGHA.812@.TK2MSFTNGP10.phx.gbl...
> Hello
> I have merge Replication MSSQL Server 2000 SP4, One Publisher and 5
> subscribers,
> a) Subscribers1 has inserted the record at 8 AM and Send it to
> subscribers2 & subscribers3
> b) Using DTS, but not insert directly subscribers2 DB its Inserted
> TempDB to subscribers2 DB using Store procedure.
> c) Subscribers2 users update same records at 3 PM. It means now other
> Subscribers not update those records.
> d) I changed my article
> @.property='compensate_for_errors',@.value='false'.
> e) I have facing some conflict Problems
> f) After Synchronization those records was deleted at some
> Subscriber
> g) We are Synchronization at 1 AM. For Schedule bases
>
> Here the Question.
> Why the Data going to deleted?
> Which data going to Synchronies in above case?
>
> Suppose I update row 1 following time
> Subscribers1 at 6 am
> Subscribers1 at 7 am
> Subscribers1 at 8 am
> Subscribers1 at 9 am
> Subscribers1 at 11 am
> Which data going to Synchronies in above case?
>
> Please Explaning Clearly
> Thanks
> Sam
>
>
>
>
>
>
>
|||THANKS Hilary
I need to test , let Contact You.
Sam
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:erQqQoHOGHA.2992@.tk2msftngp13.phx.gbl...
> Sam I am having problems understanding the scenario you present. Before I
> start guessing at what happened I want to explain a couple of things.
> a) compensate_for_errors - this switch means that if a conflict occurs the
> data will not be wiped out on the conflict loser. For example if a row
> with the same PK value is simultaneously inserted on the publisher and
> subscriber and the compensate_for_errors switch is set to true (true is
> default for SQL 2000, false is the default for SQL 2005) the row on the
> subscriber will be deleted and replaced with the row from the publisher.
> If the compensate_for_errors setting is set to false, the row on the
> subscriber will not be deleted - in other words - the subscribers row
> will remain. With this setting all such compensating actions will not
> occur.
> b) when you use DTS with the defaults the rows dts'd into the table are
> not logged and will not be replicated. Consult
> http://support.microsoft.com/kb/275680/en-us for more information.
> c) exactly what do you mean by "Using DTS, but not insert directly
> subscribers2 DB its Inserted TempDB to subscribers2 DB using Store
> procedure." If you mean it was DTS'd to tempdb and then from tempdb to the
> subscriber2 db, this should have been logged and any inserts or other DML
> as a result of this action should be replicated.
> d) did you run conflict viewer for a window into what is happening?
> It sounds like what happened what that in step b the rows were not logged
> and hence never made it to subscriber 1 and subscriber 3. I don't
> understand what happened in f). The conflict viewer should have a record
> of what happened.
> To answer your questions - data should not be deleted with the
> compensate_for_errors setting set to false - only true.
> From what you describe in the below scenario, if you are updating the same
> row the update should flow with each synchronization unless you are doing
> column level tracking - this would be logged as a conflict and the
> conflict winner should win the conflict - ie its data should make it to
> all the subscribers.
> If the sync doesn't happen each hour, only the final result will travel.
> For example if the sync runs at 11 am, only the final 11 am change will
> move.
> HTH
> --
> 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
>
> "Sam" <shankar@.cdscom.co.th> wrote in message
> news:Os7L2bEOGHA.812@.TK2MSFTNGP10.phx.gbl...
>

Merge Replication and Multiple Record UPDATE statements

We have a database in which global updates must be periodically made to
multiple records, usually in the hundreds or thousands.
Is this a problem when using Merge replication? Because there are individual
merge triggers on each table, is it preferable to use a cursor to make global
changes?
Also, when using View Conflicts feature, is it safe to assume that record
listed as the winner has already been replicated to all locations? If so, why
does one have to click on either the Keep Winning Change or the Resolve With
This Data button?
Is there a way to globally accept all winning changes?
The global update will take far longer with merge replication. A cursor
solution might offer better performance.
Regarding the conflict viewer, it is safe to assume that the conflict has
been resolved with the publisher and one subscriber. It might then conflict
with another subscriber, so you can't assume it has been resolved
everywhere.
The keep winning change button and the resolve with this data buttons allow
you to clear the conflict (in other words accept it) or roll it back and let
the subscribers change win.
Hilary Cotter
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
"elpepe" <elpepe@.discussions.microsoft.com> wrote in message
news:D5C598DA-05F0-4F98-A869-DA53D058D628@.microsoft.com...
> We have a database in which global updates must be periodically made to
> multiple records, usually in the hundreds or thousands.
> Is this a problem when using Merge replication? Because there are
> individual
> merge triggers on each table, is it preferable to use a cursor to make
> global
> changes?
> Also, when using View Conflicts feature, is it safe to assume that record
> listed as the winner has already been replicated to all locations? If so,
> why
> does one have to click on either the Keep Winning Change or the Resolve
> With
> This Data button?
> Is there a way to globally accept all winning changes?
|||Thanks -- that's very helpful.
There are hundreds of conflicts that remain. Is there a way to globally
accept the winner so that the conflicts are resolved everywhere?
Also, will you be writing a book on Merge replication anytime soon?
"Hilary Cotter" wrote:

> The global update will take far longer with merge replication. A cursor
> solution might offer better performance.
> Regarding the conflict viewer, it is safe to assume that the conflict has
> been resolved with the publisher and one subscriber. It might then conflict
> with another subscriber, so you can't assume it has been resolved
> everywhere.
> The keep winning change button and the resolve with this data buttons allow
> you to clear the conflict (in other words accept it) or roll it back and let
> the subscribers change win.
> --
> Hilary Cotter
> 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
>
> "elpepe" <elpepe@.discussions.microsoft.com> wrote in message
> news:D5C598DA-05F0-4F98-A869-DA53D058D628@.microsoft.com...
>
>

Merge Replication and Deletes

Hi there,
I have four databases set up with merge replication. I have a filter that
says only replicate a record if its timestamp is greater than one day ago (I
don't care about any data older than one day).
If I now go into Database #1 and delete a record that is older than one day,
I do not expect to see this record deleted from the other databases (in
other words, I expect that it would remain in the others). However, all the
deletes for records older than one day ARE being replicated to the other
databases. I'd really prefer that this didn't happen.
Does anyone know why this occurs?
Thanks,
Kevin
Because you told it to. You said that your filter says to only replicate if
the timestamp is greater than one day ago, and it's timestamp is greater than
1 day ago.
If you want it to not be replicated, then update the timestamp to the
current date first and then delete.
Robert.
"Kevin Thomas" wrote:

> Hi there,
> I have four databases set up with merge replication. I have a filter that
> says only replicate a record if its timestamp is greater than one day ago (I
> don't care about any data older than one day).
> If I now go into Database #1 and delete a record that is older than one day,
> I do not expect to see this record deleted from the other databases (in
> other words, I expect that it would remain in the others). However, all the
> deletes for records older than one day ARE being replicated to the other
> databases. I'd really prefer that this didn't happen.
> Does anyone know why this occurs?
> Thanks,
> Kevin
>
>
|||Perhaps I misspoke, I apologize. I only want to replicate data that is less
than a day old. I want to delete data that is greater than a day old. When
I delete the data that is older than one day, those deletes are replicated,
even though I don't expect that they would because of the filter.
Thanks for your help,
Kevin
"Robert Davis" <RobertDavis@.discussions.microsoft.com> wrote in message
news:E1D36A03-CF46-4EAB-BE05-31D048FDC59B@.microsoft.com...[vbcol=seagreen]
> Because you told it to. You said that your filter says to only replicate
> if
> the timestamp is greater than one day ago, and it's timestamp is greater
> than
> 1 day ago.
> If you want it to not be replicated, then update the timestamp to the
> current date first and then delete.
> Robert.
> "Kevin Thomas" wrote: