Ошибка при чтении изменений при обмене РИБ:  Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфигурация узла распределенной ИБ не соответствует ожидаемой!

Обычно такая ошибка происходит когда в центральном узле производились какие то изменения в конфигурации. ТОгда нужно было зайти в конфигуратор распределенной базы и руками ее обновить. Но сейчас так пишет и в конфигураторе F7 недоступно, тк изменений не было. Что это за глюк, может кто сталкивался ?

(0) в поиск.

Добро пожаловать на форум!
Нажми большую красную букву "Я" справа от темы...

Есть обработка отвязывающая базу от центрального узла (т.е. она перестает себя считать РИБ). Перезаливаешь конфигурацию, и снова привязываешь.

2(3) это обработка называется запуск конфигуратора с ключем /ResetMasterNode

(3) обработка громко сказано. одна строчка кода.

1. Отвязать периферийную от центральной.
2. Загрузить конфигурацию центральной (файл .cf)
3. Привязать периферийную к центральной.

http://infostart.ru/public/14814/

(6) все так и сделал. :_)

результата нет

придется идти путем 2 из этого описания..

что за 2-й путь?

ВТОРАЯ МЕТОДИКА

Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.

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

Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.

Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.

Итак, последовательность действий:

   выполняем действия 1 - 4 первой методики;
   выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
   выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
   в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
   производим загрузку файла из 4-го пункта в УБ;
   обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
   для проверки делаем несколько последовательных обменов.

Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.

Блок файла обмена из ЦБ

           <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
              <v8de:Version>106.0</v8de:Version>
              ...здесь идут блоки описания изменений конфигурации...
              <v8de:Digest1>1cf680807e97a5dc0d1ed7f901b07392</v8de:Digest1>
              <v8de:Digest2>038211651cf680807e97a5dc0d1ed7f9</v8de:Digest2>
          </v8de:Config>

нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)

           <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
              <v8de:Version>106.0</v8de:Version>
              <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
              <v8de:Digest2>11651cf680807e97a5dc0d1ed7f901b0</v8de:Digest2>
          </v8de:Config>

Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!

В остальном могу только пожелать удачи!

что за релиз? что за сервер? используется ли динамическое обновление? запускался ли толстый клиент с ключем /ClearCache?

8.2.12.96

УПП

обновление идет автоматом между двумя базами УПП с периодичностью 10 мин через регл задания

раньше все работало и тут вдруг такое..

"УПП" - неинтересно
"бновление идет автоматом между двумя базами УПП с периодичностью 10 мин через регл задания " - не интересно
"раньше все работало и тут вдруг такое.." - тоже плевать

а вот на те вопросы которые не ответил, таки да, нужно знать ответ

""бновление идет автоматом между двумя базами УПП с периодичностью 10 мин через регл задания " - не интересно" - хотя нет - что происходит если в периферии заблокировать регл.задания и обменяться вручную?

если выкл регл задание и выгрузить руками то - Конфигурация узла распределенной ИБ не соответствует ожидаемой!

почистите кэш и еще раз (6)