Люди добрые, помогите, кто может!

Сейчас у меня работает репликация сведением (MSSQL2000). Проблема состоит в следующем.
На одном из участников репликации осуществляется удаление записи из одной таблицы и связанных данных из другой. После этого выполняется вставка записей с теми же первичными ключами в обе таблицы. После репликации всего этого безобразия остаются не разрешенные кофликты, и базы уже не идентичны. Прочитав информацию о неразрешенных конфликтах, сделала вывод (возможно не верный), что репликация сведением не обращает внимания на порядок выпонения транзакций, и в начале не может удалить записи, так как есть ссылки на них, а затем не может добавить данные, так как идет нарушение первичного ключа.

Репликацию тразакций установить вообще не получилось. При попытке ее создания публикации появляется ошибка типа "ошибка в районе слова collate"

Помогите, пожалуйста, либо устранить первую проблему, либо установить репликацию транзакций.

Большое спасибо, что откликнулись!

К моему стыду не поняла, что значит «схема репликации и коммуникация серверов», поэтому, просто описываю ситуацию более подробно.
Есть главный сервер. Он является и издателем, и распространителем. Пока есть только один подписывающийся удаленный сервер. Связаны по tcp/ip.
Набор приложений, обрабатывающих БД для клиентов обоих серверов одинаков, поэтому реплицируется вся БД и необходимо отслеживать изменения на подписчике. В БД порядка 50 таблиц. Используется Push-репликация смещением, то есть инициатором синхронизации является издатель. Для всех таблиц (кроме двух на которые я и жалуюсь) репликация работает корректно.
Для двух таблиц, имеющих связь один-ко-многим, существует следующая проблема. На одном из участников репликации (не важно на каком) выполняются три запроса:
1 Из подчиненной таблицы удаляется набор записей. Критерием отбора является значение внешнего ключа.
2 Из главной таблицы удаляется запись, подчиненные записи которой удалили на предыдущем шаге.
3 В главную таблицу вставляется запись с тем же первичным ключом, что и запись, удаленная на шаге 2.
Если синхронизацию проводить после шага 2, то проблем не возникает. Если после шага 3, то возникает неразрешимый конфликт, о чем остается запись в списке конфликтов. Точнее две записи: одна о невозможности удалить запись, вторая о не возможности вставить запись из-за нарушения первичного ключа.
Никаких identity или других суррогатов в этих таблицах нет. Но на втором участнике репликации находится полная копия БД, естественно, включая и записи, удаляемые на шагах 1 и 2.
В остальных подобных ситуациях (связях 1-ко-многим), скорее всего, получиться та же проблема.

Вопрос. А может быть репликация смещением и не должна отслеживать порядок выполнения транзакций. То есть она берет таблицу и выясняет все отличия этой таблицы. Она не прерывает обработки таблицы, чтобы узнать, «ничего не произошло со связанными таблицами». Было бы здорово, если бы Вы опровергли это.

Теперь о репликации транзакций, которая, наверное, более применима в моем случае. Я пыталась ее настроить на тех же серверах при том же соединении.
Конфигурация издателя и подписчика на главном сервере проходит без проблем.
Проблемы начинаются при создании публикации. Причем, не важно выбираю я немедленные изменения на подписчике или отложенные. При создании публикации на шаге создания статей (add article ) появляется сообщение «error: incorrect syntax near “collate”». Насколько я понимаю это волшебное collate связано с обработкой строк и устанавливается для сервера, для БД и для таблиц. У меня везде одинаковый collate. Более того, я пыталась издавать таблицу без символьных полей, с тем же успехом, точнее не успехом.

Ура!!!!!!
Да здравствует Pandre!!!
Большое спасибо, глюки исчезли. Ссылочная целостность у меня правда была решена на триггерах, на у них тоже есть возможность указать not for replication