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

Signature
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
> Hello
>
[quoted text clipped - 45 lines]
>
> Sam
Sam - 27 Feb 2006 05:07 GMT
THANKS Hilary
I need to test , let Contact You.
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.
[quoted text clipped - 90 lines]
>>
>> Sam