У меня просто крыша едет 8-(((
Ситуация следующая: есть БД test1, test2, test3. В test1 создаю публикацию на таблицу t1. Создаю push subscription для test2 и test3. Тип обновления - постоянный. У test2 выставляю вес 10, у test3 - 20. Вставляю строку в test1..t1
insert into test1..t1 values ('AT1').
Даю время устаканиться - во всех трех таблицах она появляется. Затем
update test2..AccessTemplates set name = 'AT2'
update test3..AccessTemplates set name = 'AT3'
Смотрю содержимое таблиц сразу же - везде разное. После синхронизации - в test1 - 'AT3', в test2 - 'AT2', в test3 - 'AT3'. Это что - синхронизация ???!!!
Затем
update test2..AccessTemplates set name = 'AT2'
После синхронизации - в test1 - 'AT2', в test2 - 'AT2', в test3 - 'AT3'. И это тоже синхронизация ???!!!
Народ, просветите меня - может, я какие-то термины недопонимаю ? Типа синхронизация - это не обязательно сведение данных, чтобы они везде одинаковые были ?

test1 - паблишер, т.е. у него (наверное ) самый большой вес.
Конфликт, естественно, есть - изменения проводятся в одной колонке и строке. Я как раз и тестирую разрешение конфликтов для разных настроек в репликации. Только почему же данные на жертве не забили более приоритетными ? Я же не буду лазить каждый день в просмотр конфликтов, чтобы ручками там все править. Да, на паблишере сидят победившие данные, но мне надо, чтобы они были одинаковые на ВСЕХ серверах после того или иного разрешения конфликта.

Нет, совсем не так. Ну, во-первых, если изменения делает publisher, то он всегда победитель. Это логично.
Если задать подписчикам одинаковые веса и провести update на 2-х подписчиках так, чтобы это вызывало конфликт, то похоже, что срабатывает следующий алгоритм - кто первый из подписчиков приконнектился, тот и победитель. Ну, в общем, тоже трудно спорить - а как серверу понять, кто главнее, если я задаю одинаковый вес ? Conflict resolver по времени - это вещь совершенно отдельная и его надо подключать _вместо_ дефолтного резолвера по приоритетам. Кстати, к моему первому вопросу выяснилось следующее - когда я делаю подписки синхронизуемыми по необходимости, а не постоянно, то все работает нормально - приоритеты действуют и в случае конфликтов после нескольких итераций все сводится к одинаковым данным, выбранным по приоритету сервера. А вот continuously все-таки лажу порет - к единым данным не сводит в конце концов.
Это цветочки. Я вот сейчас начну time-based conflict resolver пробовать подключать вместо дефолтного. Ох, плохие у меня предчувствия...