А я бы не рисковал. Нигде нету никаких упоминаний о порядке обработки публикаций. Может они будут обрабатываться по алфавиту, может по порядку создания, может еще по чему. Подозреваю что ситуация о репликации сначала ведомой таблицы потом таблицы-мастера может вполне произойти....
Может попробовать положить ведомую таблицу в две публикации одновременно? Одна будет содержать и мастера и ведомых, а вторая только ведомых?

Если речь идет репликации таблиц справочников, то лично я решаю это просто: В рассылку ежемесячных обновлений/багфиксов я вкладываю и скрипты исправляющие словарные таблицы. Сами они в репликации не участвуют никак.

Александр ГoлдунЛюбопытная идея. А разве так можно? И что же отправится подписчику, если изменятся данные в таблице, на которую он несколько раз подписан через разные публикации?
Понятия не имею :) Не пробовал ни разу. Зато при наложении сообщений dbremote ругаться будет сто процентно :) Либо на ту, либо на другую пачку сообщений.

Александр ГoлдунДа, справочники. Но меняются они заметно чаще чем раз в месяц
Ну...... развожу руками. А их НАДО обновлять чаще?

А кстати, может пойти по административному пути? Типа:
- Уважаемые филиалы, в течении двух дней мы обновляем справочники. А с понедельника вы можете начать использовать новые позиции.
Или добавить в справочники поле "дата ввода в эксплуатацию"?
Или просто обновлять справочники только на консолидированной базе, тогда филиалы будут всегда работать на основе уже добавленных позиций.

Александр ГoлдунА что имелось в виду под наложением сообщений dbremote?
Ну в окне dbremote пишет recieving message/applying message, recieving message/applying message... Получаем сообщение/накладываем сообщение :)

Я предполагаю, что если мы вставляем запись в такую таблицу с двойной подпиской она должна реплицироваться по обеим подпискам... Соотвественно когда получатель обрабатывает пришедшие сообщения он накладывает сообщение от одной подписки. Потом пытается наложить сообщение от второй... оно должно выругаться на совпадение первичного ключа.
Если не ругается, то скорее всего я где-то ошибаюсь, а возможно сайбезы просто предусмотрели такой изврат? :)

Главное зло это не foreign keys, а сами удаленые базы :) Вот если бы можно было бы заставить все филиалы работать с одной общей базой... мммм... :)