Deleted record

Suppose I delete a record in a database at 12pm.
And one staff modified the same record in another database at 1 pm.
Aftere the merge replication, does that record still in both databases or
not.
By default a row deleted at the publisher will be replicated to all
subscribers as a delete. The updated row on the subscriber would be logged
as a delete. A delete originating at all subscribers would be logged as a
conflict and be replaced with an update flowing from the subscriber.
If a row was deleted at a subscriber and then updated at another subscriber
the first one in would remain, and the later one would be rolled back and
logged in the conflict table.
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
"Man Utd" <alanpltseNOSPAM@.yahoo.com.au> wrote in message
news:%23oN$CLqKGHA.140@.TK2MSFTNGP12.phx.gbl...
> Suppose I delete a record in a database at 12pm.
> And one staff modified the same record in another database at 1 pm.
> Aftere the merge replication, does that record still in both databases or
> not.
>
|||Not really.
If you had the following:
UserA deletes row at noon on Server1 and UserB updates that row on Server2
at 1PM, if the merge engine does not synchronize between the delete and the
update, then you have created a conflict that I refer to "update of a
non-existent row". In this case, if your conflict resolution states that
Server1 should win, then the delete will go through to both servers and the
update will be logged in the conflict table at the publisher. If your
conflict resolution states that Server2 should win, then the update is
applied to both servers and the delete is logged to the conflict table at
the publisher.
However, if UserA deletes row at noon on Server1 and UserB updates that row
on Server2 at 1PM, and the merge engine performed a synchronization cycle
between the delete and the update, then nothing would happen. The update
would change zero rows since the row would not exist in the database. Since
no rows had changed, the merge update trigger would simply return without
logging anything into MSmerge_contents.
The piece of the merge trigger that governs this behavior is as follows:
declare @.article_rows_updated int
select @.article_rows_updated = count(*) from inserted
if @.article_rows_updated=0
return
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eCpAC8sKGHA.2064@.TK2MSFTNGP11.phx.gbl...
> By default a row deleted at the publisher will be replicated to all
> subscribers as a delete. The updated row on the subscriber would be logged
> as a delete. A delete originating at all subscribers would be logged as a
> conflict and be replaced with an update flowing from the subscriber.
> If a row was deleted at a subscriber and then updated at another
> subscriber the first one in would remain, and the later one would be
> rolled back and logged in the conflict table.
> --
> 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
> "Man Utd" <alanpltseNOSPAM@.yahoo.com.au> wrote in message
> news:%23oN$CLqKGHA.140@.TK2MSFTNGP12.phx.gbl...
>