Есть центральная база и периферийная БП 3.0. Внес изменения в центральную, сделал обмен, скинул файл обмена на флешку и поехал к к периферийной базе. Там загрузка вывалилась с ошибкой, ошибка преобразования значения какого то. Отвязал базу, внес изменения и привязал обратно. Теперь вопрос. Главная база будет каждый следующий обмен пытаться отправить изменения в конфигурации?

Да, пока не получит ответ о принятом сообщении.

(1) Как обмануть?

(2) Может лучше дать ей ответ?

Или сделать начальный образ )))

(2) а зачем ее обманывать. сделай синхронизацию как ей хочется и все. Или отдели передачу данных обменом от того плана, где устновлена галка РИБ (зачем она там нужна, хз)

(2) Измени номер принятого сообщения в плане обмена и снеси регистрацию изменений

(3) Как дать ей ответ? Изменения ф периферийку я ж руками внес, обменом что то не захотело.

(7) изменения чего?

(6) Если регистрацию изменений снять, она забудет что отправляла изменения конфы?

+(1) и не будет принимать сообщения обмена от периферийной базы.

Ты зачем отвязыва/изменял/привязывал? Все изменения конфигурации - на центральном узле.

"Ты зачем усы сбрил, дурик?"(цы)

(2) Выгрузить конфигурацию периферийной базы и загрузить в центральную. Но я тебе этого не советовал :)

(8) РС добавил и по мелочи в формах изменения.

(10) Я ж говорю, обменом не хотели изменения переноситься, ошибка вывалилась. А еще раз за фалом обмена ехать через пол города не хотелось.

(12) Проведи уже интернет

(7) Ну и? То есть твоя конфа на переферии вроде как стала ожидаемой в ЦУ. Выгрузи ответ из переферии и загрузи его в ЦУ

(11, 12) ну так надо было (все равное физически ехал туда) не обменом конфигурацию туда подсовывать, а выгрузить CF центральной, а затем отвязать, загрузить, привязать, и после после сформировать ответку.

(13) Интернет на днях только будет, пока я выступаю почтовым голубем с флешкой.

(14) толку не будет - там контрольное значение из центральной пишется в хмл - оно совпадать не будет

*(10) Эээ... если вдруг кто не понял, то "Ты" - обращение к ТС, а не к Волшебнику  :)

(14) Я после того как обратно привязал сделал выгрузку из периферии, только не уверен что в этом ответе есть данные для главного узла, что конфа обновлена.

(17) Да, точно. Я просмотрел, что изменения вносились не загрузкой CF

(16) слушай сюда :)
отвяжи ты этот РИБ несчастный убери галку РИБ, протесть это дело, весб обмен будет гулять только данными. Изменения конфига будешь накатывать как все нормальные люди - обновлениями, а не обменами

(21) Ну тогда каждый раз при обновлении конфы в центре надо будет и пф обновлять.

PS: внес изменения в конфигурацию подчинённого узла? Молодца, ТС! Теперь восстанавливай идентичность конфигураций. Как? Я уже говорил выше - выгрузкой/загрузкой конфигураций.

(19) Да, (14) не катит уже. Лучше всего сделать (15)

(23) Я и периферийку изменения загрузкой конфы и внес. Не руками.

(22) ну а сейчас не тоже самое? так-то хоть просто будет известно, что перезаписывание отчета для работы в главной и не нужного для работы на периферийке не вызовет коллапса при попытке обменяться данными.
Нужно все-таки по характеру передаваемых данных смотреть, нужно все время вместе с ними конфиг контролировать или это уже лишнее

Я так понимаю, в этом случае центр увидит ответ что конфы совпадают?

(25) А если сделал Загрузить из файла - то все правильно сдела. Ответка после обратной привязки переиферийки и регистрация в центральной снимется

(27) да. там строковое значение в пакете есть - оно будет одинаковым. Но Центру вроде как на это значение пофиг. Если номер пакета в ответке его устроит, то регистрацию он сам снимет только по номеру.

(21) а обмен данными как производить?

(29) Ок, попробую, как в центр поеду. Спасибо.

(30) По плану обмена данными
В любом плане обмена регистрация данных происходит согласно правил регистрации, которым в общем-то все равно какие там в конфигурации чудеса происходят. Мы же про данные говорим, а не про метаданные объектов конфигурации.

Получается что флажок РИБ просто включает регистрацию изменений в метаданных, дополнительно к таким же по смыслу флажкам в настройке плана обмена в поле Состав. Они даже на форме этого объекта метаданных рядышком находятся визуально :)
И помимо просто регистрации изменений есть еще доп-функционал по созданию первичного образа узла периферийной базы, что для обмена данными в текущем состоянии уже не актуально.

Ох уж этот Фрэнки. Чему он учит Zombi?

Я то могу РИБ-обмены проводить с НЕ идентичными конфигурациями узлов, но вот не уверен, что у ТС дело наладится без преславутого "Конфигурация узла распределенной ИБ не соответствует ожидаемой" :))

(33) и что нужно делать, чтоб РИБ обмен работал даже когда конфиги не идентичны друг другу?

может там где-то инструкция опубликована на эту тему - пойду читать тогда. Если нет, то я по своему - обмены данными отделяю дальше от риб-обменов и все. Это не так трудно сделать, как кажется с непривычки

(32) "Получается что флажок РИБ просто..."
Не знаю как в БП 3.0, а в моей конфигурации РИБ-обмен и обмен по прочим планам (без галки "РИБ") различными алгоритмам обрабатываются. Я не говорю про автоматизацию проведения обменов, а именно про сами алгоритмы обмена, процедуры и функции.

(36) Согласен. Признаю свою ошибку.

Там разный состав процедур доступных в контексте модуля в Объекте План обмена. Алгоритмически, по вызовам процедур, параметры вызовов у них разные сейчас. Если используешь настроенный план обмена РИБ, то простое снятие флажка у этого плана в конфигурации не прокатит. Нужно отдельно новый план обмена в конфигурацию добавлять и всю кухню ему строить. Сам точно также делал, а других плохому учить начал - ужас!

(34) Вести обмен "по правилам обмена". Правила "готовим"  в КД2 или КД3.

(37) Угу:(

Достаточно в конфигураторе выполнить глобальный поиск "РИБ" с учетом регистра - и становится ясным насколько глубоки различия алгоритмов в поддержке планов обмена.

И не только.

Первое что на ум приходит, по памяти, - это различное поведение конфигурации при изменениях предопределенных данных (это из-за того, что это "зашито" в платформу 8.3).