thanks for your reply
my scenario requires two servers to be in sync at all times therefore
merge goes out of the question and similarly transactional with
updatable subscribers also becasue the volume at both ends are high.
Therefore my only way out is p2p which is great exept if data is
updataed at the same time we get an inconsistent state (in reality
probability ~ 0 )
i didnt get the adding of column part. In case of updates (key concern
as insert have been taken care of by partitioning) the value of that
column will be of no use? may be i missed something
[quoted text, click to view] Paul Ibison wrote:
> Conflict detection and resolution don't form part of this methodology. You
> might want to consider merge replication instead, or follow the guidelines
> for "Nonpartitioned, Bidirectional, Transactional Replication" in BOL.
> Alternatively you can add a column that distinguishes between the
> subscribers to ensure that there can't be conflicts.
> Cheers,
> Paul Ibison SQL Server MVP,
www.replicationanswers.com .
Microsoft recommends that in a peer to peer environment that all updates
occur on one node in the system to avoid such update conflicts.
--
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 [quoted text, click to view] "Udit Ghai" <ghai.udit@gmail.com> wrote in message
news:1161251890.298073.206310@m73g2000cwd.googlegroups.com...
> hi,
> this might be a stupid question to ask
>
> we have suppose Server A and Server B having p2p2 replication
> now if i do an update at exactly same time on the same row. now both
> server will send out each of its transaction and commit the others
> transactions. now both servers are in a invalid state with each others
> data. How can we resolve this since there is no conflict? is there a
> way to stop this?
>
> All this happened becasue of the latency of the network and if we have
> a latency of say 10 seconds with high data flowing between all of them.
> we cannot use any other replication method because we want a highly
> available servers and should be in syn at all times.
>
Conflict detection and resolution don't form part of this methodology. You
might want to consider merge replication instead, or follow the guidelines
for "Nonpartitioned, Bidirectional, Transactional Replication" in BOL.
Alternatively you can add a column that distinguishes between the
subscribers to ensure that there can't be conflicts.
Cheers,
Paul Ibison SQL Server MVP,
www.replicationanswers.com .
The extra column would be there to restrict update/delete/insert access to
only the local data, while read access is granted to the data from the other
node. To keep data synchronized with bi-directional transactional
replication which is unpartitioned will require you editing the stored
procedures to hand-code your conflict resolution algorithms.
Cheers,
Paul Ibison SQL Server MVP,
www.replicationanswers.com .
