1) В merge репликации участвуют 2 таблицы - parent и child, связанные foreign key. Поймет ли SQL при различных действиях с данными, что их надо правильно обновлять ? Не получится в какой-нибудь ситуации, что сначала придут инсерты на child'ов, а потом на parent'а ? Ну и подобные ситуации...

2) Если ответ на первый вопрос, что все будет замечательно, то возникает второй: а что будет, если в таблице есть foreign key на эту же таблицу, а не на другую ? Будет ли в этом случае все нормально ?

Насчет not for replication для foreign key почитаю... Для primary key я знаю, как ее правильно использовать, а вот для fk пока не приходилось. По 2-му варианту встречный вопрос - каким образом для репликации задать последовательность передачи ? Разве я могу явно указать, какая таблица будет реплицироваться первой, а какая второй ?

Пояснение ко 2-му моему вопросу. Есть таблица с fk на себя же (ну вот надо мне так, никуда не денешься).
create table t1(
objectGUID uniqueidentifier not null unique,
name sysname not null unique,
ParentObjectGUID uniqueidentifier,

primary key (objectGUID),
foreign key (ParentObjectGUID) references t1 (objectGUID)
)

Будет ли для нее нормально проходить репликация ? То есть просечет ли сиквел, что какие-то из записей надо вставлять первыми (они являются родителями), а какие-то - потом (дети) ? Это же фактически дерево получается, которое хранится в одной таблице.

2 SergOK: если такое сообщение появляется в момент первой попытки синхронизации, то скорее всего это настройки для таблицы. Когда выбираешь статьи для репликации, то в детальных опциях можно указать, что делать с таблицей на подписчике, если она уже существует - и варианты действий (drop table and recreate, delete data with row filter, delete all data using truncate, keep the existing table unchanged). Возможно, у тебя как раз стоит 1, 2 или 3 вариант и прежде чем применять снапшот, сервер пытается очистить таблицу. Если же она не пустая и на нее ссылаются данные из других таблиц, то естественно очистить ее нельзя. "Обойти" это не получится - как ты обойдешь ссылочную целостность ? Так что выбирай - или вычищай все данные, которые ссылаются на нее или ставь 4 вариант (но он тоже чреват осложнениями).

2 All:
Ну, судя по моим экспериментам, сиквел сам разбирается во внешних кличах. По крайней мере без всяких дополнительных телодвижений связанные таблицы прореплицировались без конфликтов. И кстати, для самоссылающейся таблицы тоже все прошло успешно, хотя там и было довольно большое разветвленное дерево.