Its just you;) Kidding!
Basically merge replication does not apply transactions within a
transactional boundary. What happens is all changes which occur on the
publisher or subscriber are batched together and sent to the publisher where
they are merged. Any changes which occur on the same row are flagged as a
conflict and are resolved. Then the rows to be downloaded are batched to the
subscriber and the rows to be uploaded are batched to the subscriber.
By batched I mean put in a queue and applied on the other side as
singletons. Should a singleton update delete insert fail it will be put in a
queue and tried later during the sync.
Now should the sync be interrupted all of the unprocessed changes are moved
to the new batch and tried again the next time the sync runs.
So nothing is lost, but it could be postponed till a later sync. Merge
replication is resilient to these kinds of failure and will pick up where it
left off.
I hope this answers your question.
--
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 "Stefano Busolin" <Stefano Busolin@discussions.microsoft.com> wrote in
message news:5C777E81-F67A-486E-9231-CAAE493BDE01@microsoft.com...
[quoted text, click to view] > Hi to all,
> I'm evaluating the merge replication mechanisms. The environment that i
> considered is the merge replication between Microsoft SQL SERVER 2005, as
> consolidated database, and SQL Mobile (SQLCE 3) as remote database.
> During my evaluation, I found an important issue that, if confirmed, for
> sure will make my company to decide to give up such replication
> technology.
> This issue is the "non data rollback" when the synchronization fails.
>
> I mean, suppose there are 10000 new db records in the consolidated
> database
> and that a sql mobile db starts a new synchronization (so these 10000
> records
> should be downloaded to the client). After a while, but before the end of
> this download, suppose that the connection fails and so the
> synchronicazion
> stops in the middle of the process.
> I observe that the subset of records that have been successfully
> downloaded
> and added to the remote database remain as persisted; there is no rollback
> when the replication fails, the operations are not executed inside a
> transaction.
>
> The same happens for the upload process.
>
> Please, is it me making a mistake or actually there is no rollback when
> the
> synchronization fails ?
> If there's no rollback, how does the "real world" face such problem ?
>
> For example, suppose that the client had to upload some records
> representing
> the header of an order and the rows of the order detail of the same order;
> if
> the sync fails during the upload phase, in the consolidated there could be
> the header and only a subset of the total rows (order details). Such
> situation would be unacceptable for us (I know that a subsequent sync
> would
> fix the situation but it is not anyhow acceptable).
>
> Many thanks in advance.
> Stefano Busolin
>
