Sync koszmar - czy można używać replikacji scalania (lub RDA) między 2 instancjami SQL CE bez usług IIS?

Question

Mamy do czynienia z następującym problemem, który polega na utrzymywaniu następujące zsynchronizowane:

• 1 Scentralizowane Server (IIS/MSSQL 2005)
• Wielu klientów pulpitu WPF dystrybuowanych przez ClickOnce
• Wielu klientów mobilnych - (Windows CE)

alt text http://img502.imageshack.us/img502/8246/deployment.png

Z tych kolczastych ograniczeń:

• wszystkich relacji synchronizacji są dwukierunkowe
• pulpit & węzły mobilne wymagają trybie offline
• węzły mobilne nie można zsynchronizować z serwerem centralnym, ale są synchronizowane z węzłów stacjonarnych przez USB. Węzły pulpitu działają jako serwer dla klientów mobilnych, a nie serwera centralnego. Aktualizacje z węzłów mobilnych muszą następnie zostać przeniesione na serwer centralny z uwagi na synchronizację z pulpitem, a następnie zsynchronizowanie tego pulpitu z serwerem centralnym. Uff.

Nasty.

Aby zsynchronizować pulpit i serwer wiemy, że możemy korzystać z replikacji scalania - wszystko to jest dobre dla serwera będącego dostawcą, a komputer dla subskrybenta. ALE co z synchronizacją węzłów mobilnych i stacjonarnych? Pozornie Desktop nie może być wydawcą bez serwera SQL + ISS, prawda? Możemy zainstalować MSSQL CE tylko na pulpicie.

Nawet gdyby tak było, czy węzeł mógł być jednocześnie subskrybentem i wydawcą? Podejrzewam, że ta konfiguracja nie jest obsługiwana przez architekturę Merge Replication - pozornie hub i spoke jest jedynym obsługiwanym modelem.

Staramy się ustalić, czy możemy wyeliminować RDA lub połączyć replikację jako możliwe rozwiązanie - jeśli tak, prawdopodobnie zastosujemy MS Sync Framework.

Być może są inne technologie, które moglibyśmy rozważyć?

Dzięki wszystkim

Ashley

UPDATE: my dopiero się rozpoczął o grę z MS Sync Framework i skały!

Answer 1

Z przyczyn, które nie są bezpośrednio związane z konkretnym pytaniem, myślę, że można śmiało wyeliminować replikację RDA/Merge jako możliwe rozwiązanie. Microsoft nie ogłasza tego (z oczywistych powodów), ale replikacja scalająca nie jest w 100% niezawodna w warunkach, w których połączenie sieciowe może zostać przerwane w połowie procesu replikacji (co zdarza się dość często w przypadku klientów Windows Mobile).

W wyniku tego problemu zmiany wprowadzone w bazach danych klientów czasami nie są w pełni propagowane do głównej bazy danych, ale nie można uzyskać wykrywalnego wskazania, że ​​tak się stało. Jak można sobie wyobrazić, jest to zła rzecz, szczególnie jeśli sprzedałeś swojego klienta w tym rozwiązaniu, opierając się na założeniu, że RDA działa tak jak w reklamie.Jedynym rozwiązaniem krótkoterminowym, które znaleźliśmy w tym problemie, było zaimplementowanie bardzo przylegającego procesu podwójnej nadmiarowości, aby potwierdzić, że każdy rekord dodany lub zmodyfikowany na kliencie trafił na serwer bez błędu. Długotrwałe rozwiązanie polegało na tym, aby nigdy więcej nie używać RDA do niczego.

Ten problem mógł zostać rozwiązany w ostatnich wersjach RDA (nasz problem wystąpił w najnowszej wersji 2 lata temu), ale nigdy się nie dowiem (raz ugryziony dwa razy nieśmiały).

Aktualizacja: przy okazji, miałem wielu ludzi, z którymi rozmawiałem na ten temat (w tym technicy wsparcia Microsoft), zaprzeczam, że to może być prawda, ale bardzo łatwo to zweryfikować: dodać kilka danych klienta, a następnie rozpocznij replikację, a następnie odciągnij kabel USB od urządzenia (zakładając, że klient jest połączony przez Windows Mobile przez ActiveSync), będąc w środku tego.

Jeśli wydaje mi się lekko urażony, częściowo dlatego, że tak właśnie musiała wypowiedzieć technika MS (faktyczny cytat): "cóż, po prostu powtarzaj - dane ostatecznie się połączą".

Answer 2

Zapoznaj się z Collaboration Scenarios (Peer to Peer) w Microsoft Framework 2.0. Dostawcy, których tam uwzględniono, umożliwiają synchronizację dwóch baz danych SQL Server Compact. Są również w stanie synchronizować się bezpośrednio z innymi dostawcami.