Здравствуйте, Dmdv, Вы писали:

D>Меняется ли что-либо для программиста?
D>По идее:
D>- connection string остается тем же самым — подключение к серверу приложений в домене филиала.
D>- вся настройка переходит в ответственность админа ( VPN и репликация )

Merge-репликация добавляет ко всем реплицируемым таблицам поле типа GUID, по этому полю производится идентификация записи. Кроме того, если вы используете поля IDENTITY — надо решить как у вас будут распределяться диапазоны значений IDENTITY между филиалами — можно сделать это автоматически — в этом случае лучше заранее хорошо подумать над размерами диапазонов, плохо если они будут слишком маленькими, а можно управлять диапазонами вручную. Вроде бы все, больше ничего не припоминаю. Да и это детали, которые в общем-то программистов касаются так, краешком

D>Насколько часто оптимально делать репликацию?

Зависит от того, насколько интенсивно обновляются данные. Мы в конце концов пришли к тому, что периоды синхронизации определялись потребностями бизнеса — некоторым филиалам необходимо было, чтобы данные передавались в центральный офис каждые полчаса, некоторым было достаточно пары раз в день.

D>Влияет ли частота репликаций на накопленные конкурентные изменения?

Не уверен, что понял вопрос.

D>Конфликты в конкурирующих изменениях:
D>Например, в одном филиале открывается ресурс №1, во втором — ресурс №1,
D>клиент сохраняет, происходит репликация — как происходит разрешение конфликтов?

Насколько я помню, разрешение конфликтов в репликации MS SQL — большая тема. Там есть всякие настройки, есть вроде бы даже возможность написать свой резолвер конфликтов. По умолчанию, опять же насколько я помню, при возникновении конфликта этот факт фиксируется в журнале репликации и вы можете или положиться на автоматическое разрешение — оно просто считает победившим то обновление, которое произошло позже по времени, или разрешить конфликт вручную — там можно просто выбрать ту версию записи, которую следует сохранить в базе. Но в нашем случае конфликты возникали редко, т.к. бизнес-процессы на предприятии были выстроены так, что при нормальной работе каждая запись на каждом этапе работы связанной с этой записью могла обновляться только в одном месте — к примеру документ порождался в филиале, потом в этом же филиале происходило несколько правок, потом работа по нему перемещалась в центральный офис — в этот момент филиал уже править документ не мог (так была система написана, еще до того, как задумались о репликации, просто бизнес-процесс такой), и т.д. Конфликты возникали крайне редко. Я думаю во многих случаях есть возможность хотя бы частично защититься от возникновения конфликтов в репликации подобным образом, на организационном уровне. В любом случае — посмотрите документацию на сервер по этой теме.

D>Думаю насчёт транзакционной репликации.

Мы ее не особо пробовали, т.ч. ничего не могу сказать.