Новая статья:
Что не рекомендуется делать в реплицируемых базах
Ошибки в дизайне баз данных не приводящие к проблемам в одиночной-базе, но препятствующие репликации данных между базами.

МарсельЭто дествительно так ? Кто-то на это нарывался ? Интересно потому как у меня реализовано так, отдельно справочники, отдельно склад. Я пологал что изменения реплицируются в ед. правильном порядке - "хронологическом", а разделение по подпискам только логическое.
Хронологический порядок измененений здесь ни при чем. Перед dbremote стоит задача - вытащить из лога изменения по двум спискам таблиц А,Б,Г, и Э,Ж,В.
В каком порядке программа будет обрабатывать эти два списка? Сначала первый потом второй или сначала второй потом первый? Вот внутри обрабатываемого списка (подписки) все изменения внутри всех перечисленных таблиц будут идти в хронологическом порядке. На основе лога базы. Но порядок обработки подписок не определен.
Подозреваю, что dbremote будет обрабатывать подписки в порядке их регистрации в списке подписок. То есть на пустой базе если создать подписку П1, потом П2, то оно и будет обрабатывать П1, потом П2. Если П1 убить, и создать П3 - возможно определение новой подписки заменит собой определение убитой? И тогда будет сначала П3, потом П2. Но это только вопрос отправки сообщений.
А как насчет получения? FTP или FILE отдадут сообщения не в алфавитном порядке, а в порядке регистрации файлов в файловой системе. dbremote сама делает сортировку приходящих сообщений. Никто не гарантирует что при одновременно приходе сообщений от двух подписок FTP не отдаст их не в том порядке, в котором их отправляли.

ASCRUSЯ не работаю с репликациями, но тут у меня все таки возникает закономерный вопрос - а не легче ли и надежнее в данной ситуации включить репликацию действий триггеров и выключить их отработку для Message Agent параметром или поставив в них "WHERE (CURRENT REMOTE USER IS NULL)" ?
Ну это уже по желанию администратора. Что покажется проще с точки зрения исправления ситуации. Если есть возможность подправить клиента - я бы подправил клиента. Если клиента поправить невозможно - выключать триггера.

ASCRUSВторой вопрос - а Вы уверены, что триггер на INSERT в консолидированной БД будет вызван после COMMIT WORK ? Я нигде в описании BOL этого не нашел.
Возможно, что и не после а вполне вовремя, но добавленные триггером строки все равно не будут видны для остатков сообщения. Вариантов такого поведения собственно говоря два - триггеры отрабатывают в другой сессии чем dbremote выдает серверу пришедшие команды, либо триггера отрабатывают после завершения сообщения. Я не знаю какой вариант более правильный. Пока они мне оба кажутся равно-возможными. Но дело все же не в том, почему так происходит, не так ли? :)