"Merge" replikace v MSSQL se používá hlavně tehdy, když má více uživatelů paralelně pořizovat data v odpojeném (offline) režimu. Bonbónkem je u "merge" replikace podpora mobilních klientů (PDA). Uživatelé se připojí, pořízená data odreplikují na server a server jim na oplátku doručí změny v datech provedené ostatními uživateli. Typickými kandidáty na integraci "merge" replikace do designu aplikace jsou systémy pro podporu obchodních zástupců v terénu. Proč se psát s vlastní komponentou pro replikaci, když je zde komponenta již dostatečně otestovaná Microsoftem na nezanedbatelném množství pokusných králíků.:) . Provoz systému s replikacemi ale přesto není triviální, protože se po čase začnou objevovat problémy, jejichž řešení po mobilním telefonu s obchodním zástupcem vyžaduje velkou dávku sebezapření a neustálého sebeujišťování, že si právě teď zasluhujete plat, takže není žádoucí mezi zuby procedit jadrné hodnocení ohledně intelektální potence protějšku, s nímž právě hovoříte.
Proto jsem pro replikace napsal manažera replikaci, jenž je natolik inteligentní, že uživatele většinou ignoruje a jen občas mu dovolí kliknout na nějaké tlačítko :) Na co byste tedy při návrhu vlastního manažera replikací neměli zapomenout?

Ještě upozorňuji, že tato doporučení se týkají hlavně mně důvěrně známé konfigurace, kdy uživatelé přistupují přes VPN k MSSQL serveru s publikací a na svém počítači jsou přihlášení pod lokálním (ne doménovým) účtem. Uživatelé mají na svém počítači databázi MSDE 2000.

1) Ověření dostupnosti lokálního databázového serveru.

2) Kontrola existence lokální databáze, do níž jsou replikována data.

3) Manažer má v rozhraní metody pro založení a zrušení lokální databáze. V konfiguračním souboru je cesta k souborům se skripty pro zrušení a založení databáze.

4) Ověření dostupnosti serveru (počítače) s replikacemi - "Ping".

5) Zjištění, že na serveru běží MSSQL. Prakticky se jedná o ověření, že se lze připojit na port, na němž "poslouchá" MSSQL (standardně se jedná o port 1433).

6) Manažer musí umět založit novou "subscription". "Subscription" je aktivní relace mezi jedním klientem replikace a MSSQL. Na "subscription" je navázána kompletní historie provedených replikací a prohlédnout si ji můžete v Enterprise Manageru. Po uplynutí nastaveného intervalu neaktivity replikace jsou "subscription" na serveru vymazány. Když obchodní zástupce odjede na čtrnáctidenní dovolenou, tak za existenci této metody si můžete dát pořádného panáka Four Roses. Lépe dva:)

7) Komplementární k metodě pro založení "subscription" je pochopitelně metoda pro zrušení staré "subscription".

8) Reinicializace "subscription" bez ztráty existujících lokálních dat. Například při podezření na neúplné schéma databáze u klienta je nutné znovu doručit inicializační snapshot se schématem. Je zbytečné zakládat novou "subscription", postačí reinicializace stávající.

9) Ověření dostupnosti složek, ve kterých je uložen snapshot. Inicializační snapshot musí být před zahájením replikace dostupný. Ověření dostupnosti složek probíhá až po impersonaci uživatele (viz bod 11).

10) Ověření dostupnosti pracovní složky na lokálním počítači, ve které je rozbalován snapshot. Ověření dostupnosti složky probíhá opět až po impersonaci uživatele (viz bod 11).

11) Impersonace speciálního uživatele, který má doménový účet v síti s MSSQL serverem, na němž je vytvořena publikace. Účet má přístup jen k složkám se snapshoty a k lokálnímu pracovnímu adresáři replikace. Celá replikace běží pod tímto speciálním účtem. Impersonaci nemůžete provádět na počítačích, na kterých jsou nainstalovány operační systémy Windows 98 nebo ME.

12) A samozřejmě musíte mít metodu pro spuštění replikace.

A na konec. Měli byste zájem o nějaký podrobný tutorial o vytváření replikací?