Эта ошибка является типичной для . Ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой» является системной. В основном возникает из-за аварийного завершения работы во время обмена данными по УРИБ.
Решить это можно достаточно простым способом. Рассмотрим его.
Инструкция
1. Сделайте копии баз, над которыми будут производиться работы (В конфигураторе «Администрирование - Выгрузить информационную базу»).
2. Запустите конфигуратор главной базы узла РИБ.
3. Сохраните конфигурацию центрального узла в файл базы данных («Конфигурация — Сохранить конфигурацию в файл…»)
4. Откройте конфигуратор базы подчиненного узла.
Получите 267 видеоуроков по 1С бесплатно:
5. Снимите конфигурацию подчиненного узла с поддержки (Конфигурация — Поддержка — Настройки поддержки — Снять с поддержки):
6. Загрузите конфигурацию базы данных («Конфигурация — Загрузить конфигурацию из файла…»).
8. После реструктуризации необходимо зайти в режим предприятия и установить главный узел конфигурации. Это сделать можно с помощью специальной обработки — . Обработка работает как в режиме управляемого приложения, так и в режиме обычного приложения.
9. В обработке необходимо выбрать главный узел и нажать «Выполнить»:
10. Готово! Попробуйте запустить обмен, система должна корректно выполнить обмен.
Почему возникает ошибка
Вообще говоря, часто употребляемое понятие «Информационная база 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С, изучить весь функционал и
Здравствуйте, уважаемые читатели нашего блога сайт! Сегодня поговорим об
исправлении двух ошибок
, которые могут возникнуть при обмене в в распределенной информационной базе (РИБ). Такие ошибки могут возникнуть, если вы изменили конфигурацию вашей базы и пытаетесь передать эти изменения из центральной базы в периферийную. Например, способом, который был описан . Давайте приступим!
Вот такие сообщения могут появиться при попытки сделать обмен при помощи РИБ:
«Данные принимаются от узла, для которого
зарегистрированы изменения конфигурации.
Необходимо произвести перенос изменений
конфигурации в узел.»
«Конфигурация узла распределенной ИБ
не соответствует ожидаемой!»
Давайте рассмотрим шаги, которые помогут исправить ситуацию. Перед тем как начнем, сделаем наших информационных баз!!!
- Возьмем файл конфигурации с обновлением, откроем центральную базу в Конфигураторе и загрузим его (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
- Зайдем в и сделаем выгрузку в файл для периферийной базы:
- Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выбрем пункт «Записать изменения…».
- Теперь займемся периферийной ИБ. Откроем ее в монопольном режиме, чтобы никого из пользователей не было, а также закроем Конфигуратор. Теперь необходимо запомнить узел, который является главным для текущей базы. Откроем Операции-Планы обмена-Выбрать ваш план обмена (например, «По складу»). В списке планов обмена главным узлом является элемент с желтой пиктограммой. Эта информация пригодится нам в седьмом пункте. Откроем обработку и нажмем кнопку «Отменить назначение главного узла».
- Теперь откроем периферийную ИБ в Конфигураторе и загрузим тот же файл конфигурации, который мы загружали на первом шаге в центральной базе (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
- Изменим настройку поддержки (Конфигурация-Поддержка-Настройка поддержки…). В диалоге выделим в таблице ячейку на пересечении первой строки и второй колонки. Затем двойным нажатием вызовем диалог «Настройка правил поддержки». В нем поставим флаг «Установить для подчиненных объектов» и нажмем кнопку «ОК». Закроем диалог настройки поддержки, нажав кнопку «Закрыть». Сохранить ИБ (F7). Закроем Конфигуратор.
- Теперь опять откроем периферийную ИБ в монопольном режиме 1С:Предприятие, чтобы никого из пользователей не было, а также закроем Конфигуратор. Откроем обработку УстановкаГлавногоУзлаБД.epf и выберем план обмена, который мы хотим установить главным узлом (в четвертом пункте мы запоминали этот узел). Затем нажмем кнопку «Установить главный узел». После этого текущая ИБ снова станет периферийной.
- Теперь в текущей ИБ (периферийной) откроем планы обмена и загрузим файл с обменом из Центральной базы, который мы получили на третьем шаге:
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Если все прошло успешно, то сделаем выгрузку обмена для Центральной базы в текущей ИБ (периферийной):
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выберем пункт «Записать изменения…».
- В диалоге укажем путь и имя файла обмена. Нажмем кнопку «ОК».
- Теперь попробуем загрузить этот файл в Центральной базе, откроем ее в режиме 1С:Предприятие:
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Выделим план обмена в списке-Правой кнопкой вызовем контекстное меню и выбрать пункт «Прочитать изменения…»
- В диалоге выберем файл обмена. Нажмем кнопку «ОК».
Чтобы избежать проблем с рабочими копиями сделайте сначала
Распределенная информационная база (РИБ) достаточно часто используется для организации работы филиалов и подразделений, позволяя оперативно обмениваться информацией, сохраняя нужную степень автономности. Несмотря на то, что данная технология достаточно надежна, время от времени ломается и она. Сегодня мы рассмотрим одну из довольно распространенных ошибок: Расскажем о причинах ее возникновения и методах борьбы с ней.
Начнем, как всегда, с начала. После того, как вы создали РИБ все изменения в конфигурацию информационной базы можно вносить только в главном узле. Впоследствии, при следующем обмене, все изменения будут переданы в подчиненные узлы и автоматически применены там. Но гладко было на бумаге...
На практике иногда случается так, что между сеансами обмена, особенно если на периферии плохо с каналом, конфигурация главного узла успевает измениться дважды. Например, внесли изменения, выгрузили, периферийная база изменения получила, но еще не применила их, что может занять некоторое время, и подтверждения еще не прислала. Если в этот промежуток внести изменения еще раз и снова выгрузить обмен, то получится, что центр ожидает увидеть в периферийном узле конфигурацию №1 и попытается обновить ее на конфигурацию №3, а по факту столкнется там с конфигурацией №2. Иногда подобная ситуация возникает при динамическом обновлении центральной базы. В итоге обмен станет невозможным, и вы получите сообщение о том, что Конфигурация узла распределенной ИБ не соответствует ожидаемой!
В общем мораль этой истории проста - не ведите активную доработку рабочей базы, а если ведете, то завершайте все сеансы обмена до внесения следующих изменений. Но как быть, если такая неприятность все-же произошла?
Решение "в лоб" - создать новый образ подчиненного узла, однако на практике он обычно неприменим. Как правило возникновение серьезной ошибки при обмене фиксируется не сразу, а через некоторое время после того, как перестали поступать оперативные данные из периферийных баз. В зависимости от расписания обмена между моментом возникновения проблемы и ее обнаружением может пройти целый рабочий день, а то и более.
Здесь стоит кинуть камень в огород разработчиков, которые выдают как ошибку и точно также подсвечивают красным ситуацию Номер сообщения меньше или равен номеру ранее принятого сообщения , которая в общем-то является вполне нормальной. В итоге у пользователей восприятие ошибок притупляется, и они просто перестают читать выводимые сообщения, считая, что все хорошо и просто другая сторона еще не сделала обмен у себя.
Но вернемся к нашей ошибке. Решение довольно простое и лежит на поверхности: привести конфигурацию периферийной базы к ожидаемой, т.е. привести ее в соответствие с конфигурацией центрального узла. Но на практике сделать это не так просто. Если мы откроем периферийную базу в конфигураторе, то увидим, что изменения заблокированы средствами управления РИБ.
Чтобы изменить конфигурацию подчиненного узла потребуется временно отключить его от центральной базы. Для этих целей можно воспользоваться одной из обработок, которых достаточно представлено в сети, либо отключить ИБ от центрального узла с помощью параметра запуска Конфигуратора /ResetMasterNode .
Откройте командную строку и введите (с учетом версии платформы и реального пути установки):
"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" config /ResetMasterNodeПосле выполнения данной команды появится обычное окно стартера, выберите там нужную базу и нажмите кнопку Конифгуратор .
Запуска ИБ при этом не произойдет
, т.е. может показаться, что ничего не произошло, но открыв базу в Конфигураторе повторно, можно убедиться, что она отключена от главного узла и доступна для внесения изменений.
Внимание! На платформах 8.3.7 - 8.3.9 выполнение данной команды приводит к аварийному завершению работы. Ошибка исправлена в платформе 8.3.10.
Если вы не хотите возиться с командной строкой, то можно воспользоваться одной из обработок, ниже представлена та, которую используем мы, она была найдена на просторах сети, и мы внесли в нее лишь косметические правки. Обратите внимание, обработка подходит лишь для обычного приложения, для конфигураций на управляемом приложении используйте ключ запуска Конфигуратора.
Работа с ней предельно проста, запускаем ее в режиме 1С:Предприятия, через Файл - Открыть , затем просто нажимаем нужную кнопку, в нашем случае Отключить главный узел .
Теперь нам потребуется актуальная конфигурация из центрального узла. Для этого откроем центральную ИБ в Конфигураторе и выполним Конфигурация - Сохранить конфигурацию в файл . Полученный файл с расширением cf потребуется передать в периферийный узел.
Затем в периферийном узле запускаем ИБ (предварительно отключив ее от главного узла) в Конфигураторе и снимаем с поддержки. Для этого выбираем: Конфигурация - Поддержка - Настройка поддержки
.
В открывшемся окне сначала включаем возможности изменения.
А затем снимаем конфигурацию с поддержки.
Теперь можно загружать конфигурацию из файла, для этого выберите Конфигурация - Загрузить конфигурацию из файла
и укажите не переданный из центрального узла cf
-файл. После чего вы получите предупреждение о том, что текущая конфигурация не пустая. Обращаем ваше внимание, что проделываемые нами манипуляции потенциально опасны и могут привести к необратимому повреждению ИБ, поэтому перед тем, как продолжать убедитесь, что у вас есть актуальная резервная копия.
Для начала список используемых сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
- во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
- под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
...здесь идут блоки описания изменений конфигурации...
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!