Для платформ 1с 8.x при возникновении ошибки «Конфигурация узла распределенной ИБ не соответствует ожидаемой»
Методика решение проблемы
Список используемых мной сокращений:
РИБ — распределенная информационная база
ЦБ — центральная база, корневой узел РИБ
УБ — удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
во время приёма файла сообщения в УБ «упала» база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
1. выгружаем из ЦБ cf-файл;
2. отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
3. заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню «Загрузить конфигурацию из файла» (а не сравнением-объединением!!!);
4. восстанавливаем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда…
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Итак, последовательность действий:
1. выполняем действия 1 — 4 первой методики;
2. выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
3. выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
4. в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
5. производим загрузку файла из 4-го пункта в УБ;
обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен «00000000000000000000000000000000»!!!)
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
Для начала привожу список используемых мной сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
- во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
- под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
...здесь идут блоки описания изменений конфигурации...
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
В остальном могу только пожелать удачи!
Для начала список используемых сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
- во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
- под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
...здесь идут блоки описания изменений конфигурации...
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
Почему возникает ошибка
Вообще говоря, часто употребляемое понятие «Информационная база 1С» является комплексным – в него включаются не только база данных как таковая, но и конфигурации.
- Если база данных – это, условно говоря, то, «что» хранится. Например, вводимая пользователем информация, итоговые данные;
- То конфигурация описывает, «как, в каком виде» эта информация хранится, её структуру.
Для образного и очень близкого к правде сравнения приведём простую таблицу, например справочник сотрудников организации:
- Столбцы таблицы (ФИО, Номер телефона, Адрес) образуют структуру информации и определяются конфигурацией, которую создают разработчики и программисты 1С;
- Строки таблицы, значения в них (Иванов Иван Иванович, 8-777-666-55-44, Край Раздольный, город Вольный, улица Свободная) составляют сами данные, то есть вводимую в рабочем порядке пользователями информацию:
Совсем немного усложним: в информационной базе 1С бывает, как минимум, две конфигурации:
- Основная конфигурация (далее – О.К.) – именно с ней работают программисты, изменяя или создавая для пользователей новые документы, справочники и отчёты.
- Конфигурация базы данных (далее – К.Б.Д.) – эта конфигурация влияет на то, что «видят» пользователи в процессе своей работы с программой. Если она изменилась, то эти изменения «увидят» и пользователи. Непосредственно модифицировать её разработчики не могут, изменения наследуются К.Б.Д. от основной конфигурации.
Вернёмся к нашему примеру: по просьбе пользователя программист 1С, используя средства конфигуратора, отредактировал таблицу справочника сотрудников, добавив туда дополнительный столбец Дата рождения. Для этого ему надо было пройти два этапа:
- На первом этапе вносятся необходимые изменения в основную конфигурацию, то есть в таблицу добавляется столбец Дата рождения;
- На втором этапе обновляется конфигурация базы данных, то есть в неё наследуются от О.К. сделанные на предыдущем этапе изменения.
Таким образом, рассматриваемая в этой статье ошибка «Конфигурация базы данных не соответствует сохраненной конфигурации» возникает, когда уже закончен первый этап (изменена О.К.), но ещё пока не осуществлён второй (обновление К.Б.Д.) – две конфигурации различаются, не соответствуют друг другу.
Напоследок, прежде чем переходить к решению проблемы, ещё раз обратим внимание, что второй этап, то есть обновление К.Б.Д., может быть не выполнен не только из-за решения программиста отсрочить его, но и, к примеру, из-за аварийного преждевременного завершения обновления конфигурации.
Важно: Перед каждыми производимыми модификациями информационной базы и других файлов, относящихся к 1С, не забывайте делать резервные копии. Как сделать резервное копирование базы в 1С 8.3 читайте Или смотрите в нашем видео уроке:
Что делать?
Существует несколько возможных алгоритмов действий, выбор какого-либо из них зависит от разных факторов: квалификации и полномочий пользователя, зоны ответственности за администрирование 1С и др.
Игнорировать изменения
Если не вносили никаких изменений в основную конфигурацию, но необходимо продолжать работу в программе 1С Предприятие 8, в том числе и до того момента, когда ответственный за обновление завершит свою работу, то есть выполнит 2-й этап. Или же пока не выяснятся причины произошедшего и не внесутся исправления, то можете игнорировать данное сообщение с ошибкой.
Просто каждый раз при запуске информационной базы соглашайтесь с предложением продолжить, нажимая кнопку «Да». Функциональность приложения от этого не изменится, останется прежней:
Можно и вовсе принудительно убрать это сообщение, прописав ключ /DisableStartupMessages в параметрах запуска информационной базы:
- В окне программы запуска (пометка «А») выделяем нашу базу данных и нажимаем кнопку Изменить, после чего откроется окно редактирования свойств ИБ (пометка «Б»):
- Нажатием кнопки Далее перелестнём первую страницу свойств и перейдём к следующей странице, где можно указать параметры запуска ИБ. В свойстве Дополнительные параметры запуска прописываем параметр /DisableStartupMessages:
- Нажимаем кнопку Готово и возвращаемся к окну программы запуска, где запускаем ИБ по кнопке 1С:Предприятие:
Теперь при запуске базы данных 1С 8.3 не будете видеть стартовое сообщение: «Конфигурация базы данных не соответствует сохраненной конфигурации» и программа 1С Предприятие будет запускаться в привычном порядке.
Примечание : Кроме того, рассмотренный параметр подавляет следующие стартовые сообщения:
- “Возможностей Вашего компьютера недостаточно для редактирования справки по конфигурации. Для редактирования справки необходимо установить Microsoft Internet Explorer версии 7.0 или выше”;
- “Возможностей Вашего компьютера недостаточно для редактирования html-документов, в том числе разделов справки. Для редактирования html-документов необходимо установить Microsoft Internet Explorer версии 7.0 или выше. В данном запуске редактирование html-документов будет недоступно”.
Принять изменения
- Воспользоваться командой главного меню: Конфигурация – Обновить конфигурацию базы данных ;
- Нажать клавишу F7 клавиатуры;
- Нажать на специальную кнопку панели инструментов (см. изображение ниже);
- В процессе отладки (для информации; в статье рассматриваться не будет):
Примечание: По умолчанию открываемое слева окно конфигурации и есть основная конфигурация; значок в заголовке окна говорит о том, что она уже изменена и отличается от конфигурации базы данных. Последняя открывается командой главного меню: Конфигурация – Конфигурация базы данных -Открыть конфигурацию БД.
Через некоторое время после команды обновления появляется финальное диалоговое окно «Реорганизация информации», служащее последним предупреждением о необратимости изменения конфигурации базы данных. В окне перечислены изменения, которые вступят в силу после нажатия кнопки Принять:
Отклонить изменения
При ровно тех же условиях, перечисленных в первом абзаце предыдущей главы, можете принять решение сделать откат изменений основной конфигурации, то есть убрать их, привести эту конфигурацию к состоянию, соответствующему состоянию конфигурации базы данных.
Для этого надо выполнить команду главного меню: Конфигурация – Конфигурация базы данных – Вернуться к конфигурации БД :
Итак, согласившись продолжить, мы откатываем О.К. к конфигурации базы данных.
На сайте можно ознакомиться с по конфигурации 1C Бухгалтерия 8.3.
Чтобы научиться работать в программе 1С, изучить весь функционал и
Эта ошибка является типичной для . Ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой» является системной. В основном возникает из-за аварийного завершения работы во время обмена данными по УРИБ.
Решить это можно достаточно простым способом. Рассмотрим его.
Инструкция
1. Сделайте копии баз, над которыми будут производиться работы (В конфигураторе «Администрирование - Выгрузить информационную базу»).
2. Запустите конфигуратор главной базы узла РИБ.
3. Сохраните конфигурацию центрального узла в файл базы данных («Конфигурация — Сохранить конфигурацию в файл…»)
4. Откройте конфигуратор базы подчиненного узла.
Получите 267 видеоуроков по 1С бесплатно:
5. Снимите конфигурацию подчиненного узла с поддержки (Конфигурация — Поддержка — Настройки поддержки — Снять с поддержки):
6. Загрузите конфигурацию базы данных («Конфигурация — Загрузить конфигурацию из файла…»).
8. После реструктуризации необходимо зайти в режим предприятия и установить главный узел конфигурации. Это сделать можно с помощью специальной обработки — . Обработка работает как в режиме управляемого приложения, так и в режиме обычного приложения.
9. В обработке необходимо выбрать главный узел и нажать «Выполнить»:
10. Готово! Попробуйте запустить обмен, система должна корректно выполнить обмен.
