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

Начнем, как всегда, с начала. После того, как вы создали РИБ все изменения в конфигурацию информационной базы можно вносить только в главном узле. Впоследствии, при следующем обмене, все изменения будут переданы в подчиненные узлы и автоматически применены там. Но гладко было на бумаге...

На практике иногда случается так, что между сеансами обмена, особенно если на периферии плохо с каналом, конфигурация главного узла успевает измениться дважды. Например, внесли изменения, выгрузили, периферийная база изменения получила, но еще не применила их, что может занять некоторое время, и подтверждения еще не прислала. Если в этот промежуток внести изменения еще раз и снова выгрузить обмен, то получится, что центр ожидает увидеть в периферийном узле конфигурацию №1 и попытается обновить ее на конфигурацию №3, а по факту столкнется там с конфигурацией №2. Иногда подобная ситуация возникает при динамическом обновлении центральной базы. В итоге обмен станет невозможным, и вы получите сообщение о том, что Конфигурация узла распределенной ИБ не соответствует ожидаемой!

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

Решение "в лоб" - создать новый образ подчиненного узла, однако на практике он обычно неприменим. Как правило возникновение серьезной ошибки при обмене фиксируется не сразу, а через некоторое время после того, как перестали поступать оперативные данные из периферийных баз. В зависимости от расписания обмена между моментом возникновения проблемы и ее обнаружением может пройти целый рабочий день, а то и более.

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

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

Чтобы изменить конфигурацию подчиненного узла потребуется временно отключить его от центральной базы. Для этих целей можно воспользоваться одной из обработок, которых достаточно представлено в сети, либо отключить ИБ от центрального узла с помощью параметра запуска Конфигуратора /ResetMasterNode .

Откройте командную строку и введите (с учетом версии платформы и реального пути установки):

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

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

Внимание! На платформах 8.3.7 - 8.3.9 выполнение данной команды приводит к аварийному завершению работы. Ошибка исправлена в платформе 8.3.10.

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

Работа с ней предельно проста, запускаем ее в режиме 1С:Предприятия, через Файл - Открыть , затем просто нажимаем нужную кнопку, в нашем случае Отключить главный узел .

Теперь нам потребуется актуальная конфигурация из центрального узла. Для этого откроем центральную ИБ в Конфигураторе и выполним Конфигурация - Сохранить конфигурацию в файл . Полученный файл с расширением cf потребуется передать в периферийный узел.

Затем в периферийном узле запускаем ИБ (предварительно отключив ее от главного узла) в Конфигураторе и снимаем с поддержки. Для этого выбираем: Конфигурация - Поддержка - Настройка поддержки .

В открывшемся окне сначала включаем возможности изменения.

А затем снимаем конфигурацию с поддержки.

Теперь можно загружать конфигурацию из файла, для этого выберите Конфигурация - Загрузить конфигурацию из файла и укажите не переданный из центрального узла cf -файл. После чего вы получите предупреждение о том, что текущая конфигурация не пустая. Обращаем ваше внимание, что проделываемые нами манипуляции потенциально опасны и могут привести к необратимому повреждению ИБ, поэтому перед тем, как продолжать убедитесь, что у вас есть актуальная резервная копия.

• Файл с сообщением уже загружался в базу-приемник. Необходимо выгрузить его из базы-источника заново.

Ошибка «Ошибка при копировании файла c FTP ресурса… Ошибка работы с Интернет: Timeout was reached»

• С сайта, через который проходит обмен, не получается скопировать нужный файл. Это может быть связано с медленной работой вашего интернета или с проблемами самого сайта.
• Нужно попробовать повторить обмен через 15-30 минут.

Ошибка «Редактирование данных этого периода запрещено. Изменения не могут быть записаны…»

• Загружаемые данные содержат документы из закрытого периода.
• Нужно провести обмен под пользователям, имеющим право на изменение документов в этом периоде.

Ошибка «Необходимо выполнить обновления конфигурации базы данных. Обновление может быть выполнено в режиме конфигуратора»

• Зайти в конфигуратор.
• Выполнить пункт меню «Конфигуратор / Обновить конфигурацию базы данных».
• Если выдается вопрос с ответами только «Повтор», «Отмена», «Обновить динамически», нажать кнопку «Обновить динамически».
• Если выдается вопрос с ответами только «Повтор» и «Отмена».
  • всем пользователям выйти из 1С.
  • нажать кнопку «Повтор».
• На оставшиеся вопросы ответить утвердительно: «Да», «Принять», «ОК».
• Закрыть конфигуратор.
• Повторить загрузку из центра.

Ошибка «Конфигурация не соответствует ожидаемой», «Попытка приема изменений от неизвестной конфигурации»

• Ошибка в базе данных.
• Необходимо обратиться к специалистам.

Обмен проходит очень долго, зависает

• Поступает много данных.
  • Выясните у отправителя, выполнял ли он групповое изменение документов (проведение, замена реквизитов и т.д.).
  • Если да, оставьте компьютер с обменом на ночь.
• Большой файл не может скачаться из интернета.
  • Если файл имеет большой размер (80-100 Мб и больше), то, возможно, 1С просто не может его скачать.
  • Необходимо скачать файл и загрузить его в 1С вручную (возможно при помощи специалистов).
    • пункт меню «Операции» / Планы обмена / Полный / Кнопка на панели «Прочитать сообщение».
• База повреждена:
  • Попробуйте
• Если эти действия не помогли — придется обратиться к специалистам.

• Если исправить ошибку не удалось, звоните по телефону экстренной поддержки +7 (8512) 64-55-05.
• Наш специалист поможет вам, в каком бы городе вы не находились.

Для начала список используемых сокращений:

• РИБ - распределенная информационная база
• ЦБ - центральная база, корневой узел РИБ
• УБ - удаленная база, БД удаленного узла РИБ

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

• во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
• под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций

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

Для исправления использую 2 методики, в зависимости от ситуации.

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

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

Последовательность действий:

1. выгружаем из ЦБ cf-файл;
2. отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
3. заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
4. восстанавливем признак РИБ для УБ.

В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...

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

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

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

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

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

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

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

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

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

106.0
...здесь идут блоки описания изменений конфигурации...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

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

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

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

Эта ошибка является типичной для . Ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой» является системной. В основном возникает из-за аварийного завершения работы во время обмена данными по УРИБ.

Решить это можно достаточно простым способом. Рассмотрим его.

Инструкция

1. Сделайте копии баз, над которыми будут производиться работы (В конфигураторе «Администрирование - Выгрузить информационную базу»).

2. Запустите конфигуратор главной базы узла РИБ.

3. Сохраните конфигурацию центрального узла в файл базы данных («Конфигурация — Сохранить конфигурацию в файл…»)

4. Откройте конфигуратор базы подчиненного узла.

Получите 267 видеоуроков по 1С бесплатно:

5. Снимите конфигурацию подчиненного узла с поддержки (Конфигурация — Поддержка — Настройки поддержки — Снять с поддержки):

6. Загрузите конфигурацию базы данных («Конфигурация — Загрузить конфигурацию из файла…»).

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

9. В обработке необходимо выбрать главный узел и нажать «Выполнить»:

10. Готово! Попробуйте запустить обмен, система должна корректно выполнить обмен.

Здравствуйте, уважаемые читатели нашего блога сайт! Сегодня поговорим об
исправлении двух ошибок , которые могут возникнуть при обмене в в распределенной информационной базе (РИБ). Такие ошибки могут возникнуть, если вы изменили конфигурацию вашей базы и пытаетесь передать эти изменения из центральной базы в периферийную. Например, способом, который был описан . Давайте приступим!

Вот такие сообщения могут появиться при попытки сделать обмен при помощи РИБ:

Давайте рассмотрим шаги, которые помогут исправить ситуацию. Перед тем как начнем, сделаем наших информационных баз!!!

1. Возьмем файл конфигурации с обновлением, откроем центральную базу в Конфигураторе и загрузим его (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
2. Зайдем в и сделаем выгрузку в файл для периферийной базы:
   
   
   • Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выбрем пункт «Записать изменения…».
3. Теперь займемся периферийной ИБ. Откроем ее в монопольном режиме, чтобы никого из пользователей не было, а также закроем Конфигуратор. Теперь необходимо запомнить узел, который является главным для текущей базы. Откроем Операции-Планы обмена-Выбрать ваш план обмена (например, «По складу»). В списке планов обмена главным узлом является элемент с желтой пиктограммой. Эта информация пригодится нам в седьмом пункте. Откроем обработку и нажмем кнопку «Отменить назначение главного узла».
4. Теперь откроем периферийную ИБ в Конфигураторе и загрузим тот же файл конфигурации, который мы загружали на первом шаге в центральной базе (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
5. Изменим настройку поддержки (Конфигурация-Поддержка-Настройка поддержки…). В диалоге выделим в таблице ячейку на пересечении первой строки и второй колонки. Затем двойным нажатием вызовем диалог «Настройка правил поддержки». В нем поставим флаг «Установить для подчиненных объектов» и нажмем кнопку «ОК». Закроем диалог настройки поддержки, нажав кнопку «Закрыть». Сохранить ИБ (F7). Закроем Конфигуратор.
6. Теперь опять откроем периферийную ИБ в монопольном режиме 1С:Предприятие, чтобы никого из пользователей не было, а также закроем Конфигуратор. Откроем обработку УстановкаГлавногоУзлаБД.epf и выберем план обмена, который мы хотим установить главным узлом (в четвертом пункте мы запоминали этот узел). Затем нажмем кнопку «Установить главный узел». После этого текущая ИБ снова станет периферийной.
7. Теперь в текущей ИБ (периферийной) откроем планы обмена и загрузим файл с обменом из Центральной базы, который мы получили на третьем шаге:
   
   
   • Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
8. Если все прошло успешно, то сделаем выгрузку обмена для Центральной базы в текущей ИБ (периферийной):
   
   
   • Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
   • Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выберем пункт «Записать изменения…».
   • В диалоге укажем путь и имя файла обмена. Нажмем кнопку «ОК».
9. Теперь попробуем загрузить этот файл в Центральной базе, откроем ее в режиме 1С:Предприятие:
   
   
   • Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
   • Выделим план обмена в списке-Правой кнопкой вызовем контекстное меню и выбрать пункт «Прочитать изменения…»
   • В диалоге выберем файл обмена. Нажмем кнопку «ОК».

Чтобы избежать проблем с рабочими копиями сделайте сначала