Конфигурация узла распределенной иб не соответствует ожидаемой что делать
Конфигурация узла распределенной ИБ не соответствует ожидаемой 1С 8.3 (8.2)
Эта ошибка является типичной для распределенных информационных баз 1С 8.2 и 8.3. Ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой» является системной. В основном возникает из-за аварийного завершения работы во время обмена данными по УРИБ.
Решить это можно достаточно простым способом. Рассмотрим его.
Инструкция
1. Сделайте копии баз, над которыми будут производиться работы (В конфигураторе «Администрирование — Выгрузить информационную базу»).
2. Запустите конфигуратор главной базы узла РИБ.
3. Сохраните конфигурацию центрального узла в файл базы данных («Конфигурация — Сохранить конфигурацию в файл…»)
4. Откройте конфигуратор базы подчиненного узла.
5. Снимите конфигурацию подчиненного узла с поддержки (Конфигурация — Поддержка — Настройки поддержки — Снять с поддержки):
Получите понятные самоучители по 1С бесплатно:
6. Загрузите конфигурацию базы данных («Конфигурация — Загрузить конфигурацию из файла…»).
7. После загрузки необходимо сохранить и применить изменения для базы данных (клавиша F7). Соглашайтесь со всеми сообщениями системы.
8. После реструктуризации необходимо зайти в режим предприятия и установить главный узел конфигурации. Это сделать можно с помощью специальной обработки — УстановкаОсновногоУзла. Обработка работает как в режиме управляемого приложения, так и в режиме обычного приложения.
9. В обработке необходимо выбрать главный узел и нажать «Выполнить»:
10. Готово! Попробуйте запустить обмен, система должна корректно выполнить обмен.
Читайте также другие статьи по 1С:
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Конфигурация узла распределенной ИБ не соответствует ожидаемой
Распределенная информационная база (РИБ) используется для организации работы филиалов и подразделений, позволяя обмениваться информацией между ними. Технология обмена между базами достаточно надежна, но время от времени ломается и она.
Прочитав эту статью, вы:
Распределенная информационная база (РИБ)
Создание и настройка распределенной базы данных (РИБ) необходимы в случаях, когда нет возможности работать пользователям из разных мест с одной базой. Это возможно при работе с филиалами и подразделениями организации, которые территориально располагаются в разных местах, но должны обмениваться информацией с центральным офисом. Или если по принятым мерам безопасности в организациях ограничен доступ в интернет и удаленно подключиться к рабочей базе, например, через RDP нет возможности.
В этих случаях выполняют настройку распределенной информационной базы.
Базу центрального офиса, где собираются все данные, называют центральной, а базы филиалов — периферийными.
Рассмотрим создание РИБ на примере 1С:Бухгалтерия 3.0.
Настройка центральной базы
Настройка центральной базы РИБ выполняется по этапам:
Создание начального образа подчиненного узла РИБ занимает много времени. Не пугайтесь, если программа «висит» и «ничего не происходит» — просто дождитесь окончания операции, которая может длиться несколько часов.
По окончанию операции будет выдано сообщение о ее успешном завершении.
Получите понятные самоучители 2021 по 1С бесплатно:
Для настройки Сценария синхронизации нажмите кнопку Добавить и все правила будут созданы по умолчанию. Завершается настройка центральной базы сообщением, что синхронизация данных завершена.
Результат выполненной настройки в центральной базе.
Настройка периферийной базы
Настройка периферийной базы РИБ выполняется по этапам:
Следуя шагам Мастера, завершите настройку.
Результат настройки периферийной базы.
После завершения настройки в периферийной базе проверьте наличие перенесенных данных из центральной базы:
Обмен в РИБ
Будет выполнен обмен с центральной базой.
По окончанию операции данные периферийной базы будут выгружены в центральную базу, а данные центральной базы загружены в периферийную с помощью РИБ.
Аналогичные правила для центральной базы.
После того, как вы создали РИБ, все изменения в конфигурацию информационной базы можно вносить только в главном узле центральной базы. При обновлении конфигурации центрального узла будут переданы в подчиненные узлы и автоматически применены там.
Причины возникновения ошибки
Если в момент обновления конфигурации база «падает» из-за отключения электропитания или медленно работает канал обмена, конфигурация главного узла успевает измениться. а периферийного — нет.
Причин, приводящих к подобной ошибке много, но наиболее частыми можно назвать:
Обновление конфигурации центральной базы
В том случае, если периферийная база изменения получила, но еще не применила, а в центральной базе в этот промежуток вносятся изменения еще раз и снова инициируют обмен, то возникает конфликт.
Центральная база ожидает увидеть в периферийном узле предыдущие изменения и попытается обновить ее на новые, а по факту конфигурация периферийной базы еще не обновлена.
Динамическое обновление
Иногда подобная ситуация возникает при динамическом обновлении центральной базы. В итоге обмен становится невозможным, и вы получите сообщение:
Справедливости ради нужно отметить, что разработчики предусмотрели отслеживание подобных ситуаций. Если обновление не закончилось в одной из распределительных баз — работа в ней будет заблокирована и пользователь получит следующее сообщение.
Это предотвращает в большинстве случаев появление ошибки рассогласования конфигураций центральной и периферийных баз.
Но если по каким-то причинам ошибка все-таки имеет место — проблему нужно решать.
Исправить ошибку можно разными способами. Мы рассмотрим вариант с использование внешней обработки и дадим вам ссылку для скачивания обработки Главный узел на управляемой форме. Если проблема не решится — будут предложены дополнительные варианты решения проблемы.
Перед исправлением ошибки обязательно сделайте копии центральной и периферийных баз данных. Иначе вернуться к исходному варианту после неудачной попытки исправления вы не сможете.
Отключение Главного узла периферийной базы
Данная методика неоднократно помогала нам решить проблему у клиентов при получении ошибки РИБ:
Необходимо привести конфигурацию периферийной базы к ожидаемой, т.е. привести ее в соответствие с конфигурацией центрального узла. Казалось бы, чего проще! Выгрузить в файл конфигурации из центральной базы и загрузить его в периферийную. Но если мы откроем периферийную базу в Конфигураторе и попытаемся выгруженную конфигурацию центральной базы загрузить в периферийную, то увидим, что это не так просто сделать. Изменения заблокированы средствами управления РИБ.
При попытке обновить конфигурацию вручную команда Обновить конфигурацию недоступна.
Что делать? Рекомендуемая последовательность действий:
Выгрузка конфигурации ЦБ в файл
Этим файлом мы обновим конфигурацию ПБ после открепления в ней Главного узла обмена.
Открепление Главного узла в ПБ
Чтобы обновить конфигурацию ПБ вручную потребуется снять блокировку обмена. Сделать это можно только открепив Главный узел обмена. К сожалению, ни встроенной обработкой изменения реквизитов, ни работой напрямую с константой Главной узел в пользовательском режиме этого сделать нельзя. Только через внешнюю обработку.
Код этой обработки невероятно прост, всего несколько строчек, и вы можете:
Запуск выполняется пользователем с Полными правами или возможностью работать с внешними отчетами и обработками.
По окончанию операции выйдет сообщение, что Главный узел отключен.
При отключении Главного узла Конфигуратор ПБ должен быть закрыт.
Обновление конфигурации в ПБ
Примите обновление конфигурации по кнопке F7.
Подключение Главного узла в ПБ
Программа выполнит автоматическое обновление базы данных.
В открывшейся форме в поле Главный узел базы укажите тип данных Полный.
При подключении Главного узла Конфигуратор ПБ должен быть закрыт.
Выполните обмен сначала в ПБ, а после него в ЦБ. Все изменения должны загрузиться.
Корректировка файлов обмена РИБ
Если указанные выше действия не помогли и обмен проходит с ошибками — переходим к корректировке файлов обмена РИБ. При этом все действия по сопоставлению конфигураций ЦБ и ПБ, что рассмотрены выше, должны быть выполнены.
Выгрузка файла обмена из периферийной базы
Выгрузка файла обмена из центральной базы
Корректировка файла обмена из ЦБ
В файле обмена из ЦБ замените блок, содержащий информацию об изменениях конфигурации на блок из файла ПБ.
Файлы обмена находятся в папке, которую указали при настройке обмена синхронизации распределенных баз. Всего там находятся два файла:
Откройте файл обмена Message_ЦБ_ФЛ, редактором позволяющим редактировать xml-файлы, например, Блокнот.
В файле Message_ЦБ_ФЛ блок Загрузка скорректированного файла
Конфигуратор при получении данных должен быть закрыт.
После этого делаем Отправку данных и переходим в центральную базу.
Проверка обмена в центральной базой
Выполняем Получение данных в центральной базе. Если все хорошо, в отчете отразится информация о том, что данные приняты и отправлены.
Выполняем несколько последовательных обменов для проверки. Если все хорошо, в периферийной базе «красная точка» по получению данных из отчета исчезнет.
Да, все отлично. Обмен восстановлен, ошибка исправлена.
Работа с ошибками РИБ относится к разряду профессиональных и Бухэксперт8 рекомендует передавать их для исправления специалистам 1С. При работе с ошибками обязательно копируйте базы данных.
Если Вы еще не являетесь подписчиком системы БухЭксперт8:
После оформления подписки вам станут доступны все материалы по 1С Бухгалтерия, записи поддерживающих эфиров и вы сможете задавать любые вопросы по 1С.
Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно
Похожие публикации
Карточка публикации
(2 оценок, среднее: 5,00 из 5)
Все комментарии (2)
Огромное спасибо за статью. У меня все получилось.
Отлично! Спасибо, что поделились.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Вы можете задать еще вопросов
Доступ к форме «Задать вопрос» возможен только при оформлении полной подписки на БухЭксперт8
Нажимая кнопку «Задать вопрос», я соглашаюсь с
регламентом БухЭксперт8.ру >>
И снова «Конфигурация узла распределенной ИБ не соответствует ожидаемой»
Выгрузка из главной базы платформа 8.3.12.1685:
Выгрузка из периферийной базы 1 платформа 8.3.12.1685:
Выгрузка из периферийной базы 2 платформа 8.3.12.1685:
Остальные периферийные базы не приведены, однако там ситуация такая же: Атрибут V2 в ключе v8de:Digest2 отличается во всех базах, само же значение ключа на платформе 8.3.12.1685 одинаково. Обмен на платформе 8.3.12.1685 идет нормально. Вывод: для нормального обмена на 8.3.12.1685 требуется равенство значения ключа v8de:Digest2, равенство значения атрибута V2 необязательно. При попытке сделать обмен на под управлением платформы 8.3.15.1565 ситуация следующая:
Выгрузка из главной базы платформа 8.3.15.1565:
Выгрузка из периферийной базы 1 платформа 8.3.15.1565:
Выгрузка из периферийной базы 2 платформа 8.3.15.1565:
Из проведенного эксперимента следует сразу несколько выводов: Первое, ключи для сравнения в базе приемнике формируются динамически либо при открытии базы под той или иной платформой, либо перед процедурой загрузки выгрузки. Второе, для нормального обмена данными под управлением платформы 8.3.15.1565 требуется равенство не только значения ключа v8de:Digest2, но и атрибута V2, так как обмен не шел как с периферийной базой 1, так и с периферийной базой 2. Заметим, что именно в периферийной базе 1 была произведена загрузка конфигурации, выгруженной из главной базы, однако там отличаются оба ключа.
Так как ключи формируются динамически, условием восстановления обмена может быть только приведение в полное соответствие конфигураций главной и периферийных баз данных. Почему же загрузка конфигурации из главного узла и загрузка в периферийный узел не помогает? Базы у меня работают в режиме совместимости 8.2. В этом режиме многие возможности современной платформы 1С отключаются и доступа к ним нет. Было сделано предположение, что в файл конфигурации cf не попадают эти отключенные области, однако они участвуют в расчете ключей при обмене. Тут я вспомнил про возможность выгрузить конфигурацию в файлы и потом загрузить ее из этого набора файлов обратно. Понятно, что для обычных форм это бинарные файлы, но сравнить то мы их можем, и подменить отличающиеся. После выгрузки в файлы конфигураций главной и периферийной базы 1 и попытке сравнения файлов результат обескуражил: отличались по содержимому не только многие бинарные файлы, но и содержимое такого вполне читаемого файла как ConfigDumpInfo.xml.
Причины непонятны, скорее всего зарытые ошибки в конфигурации главной базы некорректно были выгружены в файлы. Для устранения этого в периферийную базу была опять загружена конфигурация из главного узла. После проведенных манипуляций обмен не восстановился:
Выгрузка из главной базы не изменилась и приведена выше.
Выгрузка из периферийной базы 1 платформа 8.3.15.1565:
Вспомнив о том, что многим помогала операция загрузки файла конфигурации из периферийной базы в главную, проделал абсолютно идиотскую операцию: загрузил в главную базу файл конфигурации, который был из нее же выгружен (ведь этот файл был только что загружен в периферийную базу). При анализе файла выгрузки из главной базы я с удивлением увидел появившийся блок с метаданными, т.е. произошло реальное изменение метаданных конфигурации (могу только предположить, что это наслоения багов старых динамических обновлений).
Этот файл выгрузки был уже нормально принят моей периферийной базой, причем обновления конфигурации периферийной базы не потребовалось, блок метаданных был молча принят периферийной базой.
После этого двухсторонний обмен восстановился:
Выгрузка из главной базы платформа 8.3.15.1565:
Выгрузка из периферийной базы 1 платформа 8.3.15.1565:
При восстановлении обмена с другими периферийными базами ( с теми у которых один ключ совпадал) я сделал попытку избавиться от этапа загрузки конфигурации из файлов, решив, что это лишнее. К сожалению ничего не получилось. Очевидно, первоначальная идея, что в этом наборе файлов содержится информация, не попадающая в файл конфигурации cf оказалась верной. На просторах интернета предлагается для восстановления обмена в РИБ вносить изменения в конфигурацию, приводящие к реконфигурации базы данных. Реконфигурация, конечно, очень полезна, а иногда даже необходима при смене платформы, но в данном случае она оказалась абсолютно бесполезной, на генерацию ключей и восстановление обмена она никакого влияния не оказала, это было проверено.
Итак окончательная последовательность действий при возникновении ошибки обмена данными в РИБ при переходе на другую, более свежую платформу 1С следующая:
Далее, скрестив на всякий случай пальцы (с продуктами от 1С возможно все), пробуем сделать обмен в РИБ.
Ваш браузер устарел, пожалуйста обновите ваш браузер пройдя по ссылке www.microsoft.com/download
1. Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Самой распространенной ошибкой при использовании распределенных баз в 1с:Предприятие 8.x является ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой». Связана она с рассинхронизацией конфигурации главного и подчиненного узла, возникать может по нескольким причинам, самая распространенная из них это динамическое обновление конфигурации. Рассмотрим основные пути решения данной проблемы, укажу способы по простоте их использования, сначала самые простые (но иногда не менее эффективные), потом более сложные:
\Local Settings\Application Data\1C\1Cv82
Можно воспользоваться готовым bat-файлом для удаление файлов кэша, как это описано в этой статье «Чистка кэша 1с».
Не денамическое обновление корневого узла.
Самый распространенный способ решения данной проблемы, он почти в 100% случаев помогает решить данную проблему, опять таки замечу, что почти в 100%, т.к. у меня возникали случаи, когда переносом конфигурации из главного узла в подчиненный проблема не решалась. Данный метод заключается в переносе конфигурации из главной базы в распределенную.
Последовательность действий:
где в качестве параметра передаем главный узел распределенной базы.
Для выполнение этих действий удобнее всего воспользоваться обработкой, которую можно скачать здесь (подходит для всех конфигураций на не управляемых формах, т.к. Розница 1.0 или УТ 10.3, огромное множество аналогичных можно найти на просторах инфостарта).
Подмена хэша конфигурации в файле обмена.
Последовательность действий:
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из главной базы:
нужно заменить на блок файла обмена из переферийной базы (обратите внимание Digest1 у файла из переферийной базы всегда равен «00000000000000000000000000000000». )
2. Номер сообщения меньше либо равен ранее принятому.
Данное сообщение может и не свидетельствовать об ошибки. Данное сообщение часто указывает на то, что все данные выгруженные для вас из распределенной базы уже были загружены ранее.
Бывают случаи, когда файл выгружается или загружается в копию базы и не может быть загружен так как нумерация файлов обмена нарушена. В таком случае помогает изменение нумерации файлов. В типовых конфигурациях это можно сделать с помощью раздела «Регистрации изменений для обмена», в старых версиях на неуправляемых формах (УТ 10.3, Розница 1.0 и т.д.) в него можно попасть из монитора обмена, а в новых (УТ 11, Розница 2.x и т.д.) в него можно попасть из раздела синхронизации данных «Состав отправляемых данных», в нем есть пункт «Изменить номера сообщений» для неуправляемых форм и «Редактировать номера сообщений» для управляемых. Номер принятого в таком случае надо ставить меньше (вплоть до 0), а номер отправленного ставить больше (можно даже 10000). После изменения номеров сообщений обмен должен начать проходить.
3. Ошибка преобразования данных XML.
На узле-отправителе проблемного сообщения откройте обработку ВыгрузкаЗагрузкаДанныхXML.epf (из состава конфигурации «Конвертация данных», находится в каталоге шаблона конфигурации после её установки), нажмите в самом низу кнопку «Недопустимые символы в плане обмена» и выберите узел-получатель. Если проверка выдаст ошибки, то вам достаточно будет устранить их непосредственно в указанных объектах и проблема будет решена.
Если же всё выше описанное не помогло решить проблему, то откройте XML файл сообщения (лучше всего открывать прямо в 1С:Предприятие 8) и посмотрите по указанному номеру строки, на каком объекте остановился прием. Теперь нужно в базе отправителе с помощью обработки «Регистрации изменений для обмена» найти данный объект и отменить по нему регистрацию, после чего обмен должен пройти. Последний способ является крайней мерой, если ничего остальное не помогло решить проблему, так как при этом проблемный объект не будет перенесен в базу приемника и ситуация может повториться при повторной регистрации проблемного объекта.
Ошибки РИБ и как с ними бороться
1. Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Самой распространенной ошибкой при использовании распределенных баз в 1с:Предприятие 8.x является ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой». Связана она с рассинхронизацией конфигурации главного и подчиненного узла, возникать может по нескольким причинам, самая распространенная из них это динамическое обновление конфигурации. Рассмотрим основные пути решения данной проблемы, укажу способы по простоте их использования, сначала самые простые (но иногда не менее эффективные), потом более сложные:
\Local Settings\Application Data\1C\1Cv82
Можно воспользоваться готовым bat-файлом для удаление файлов кэша, как это описано в этой статье «Чистка кэша 1с».
Не денамическое обновление корневого узла.
Самый распространенный способ решения данной проблемы, он почти в 100% случаев помогает решить данную проблему, опять таки замечу, что почти в 100%, т.к. у меня возникали случаи, когда переносом конфигурации из главного узла в подчиненный проблема не решалась. Данный метод заключается в переносе конфигурации из главной базы в распределенную.
Последовательность действий:
где в качестве параметра передаем главный узел распределенной базы.
Для выполнение этих действий удобнее всего воспользоваться обработкой, которую можно скачать здесь (подходит для всех конфигураций на не управляемых формах, т.к. Розница 1.0 или УТ 10.3, огромное множество аналогичных можно найти на просторах инфостарта).
Подмена хэша конфигурации в файле обмена.
Последовательность действий:
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из главной базы:
нужно заменить на блок файла обмена из переферийной базы (обратите внимание Digest1 у файла из переферийной базы всегда равен «00000000000000000000000000000000». )
2. Номер сообщения меньше либо равен ранее принятому.
Данное сообщение может и не свидетельствовать об ошибки. Данное сообщение часто указывает на то, что все данные выгруженные для вас из распределенной базы уже были загружены ранее.
Бывают случаи, когда файл выгружается или загружается в копию базы и не может быть загружен так как нумерация файлов обмена нарушена. В таком случае помогает изменение нумерации файлов. В типовых конфигурациях это можно сделать с помощью раздела «Регистрации изменений для обмена», в старых версиях на неуправляемых формах (УТ 10.3, Розница 1.0 и т.д.) в него можно попасть из монитора обмена, а в новых (УТ 11, Розница 2.x и т.д.) в него можно попасть из раздела синхронизации данных «Состав отправляемых данных», в нем есть пункт «Изменить номера сообщений» для неуправляемых форм и «Редактировать номера сообщений» для управляемых. Номер принятого в таком случае надо ставить меньше (вплоть до 0), а номер отправленного ставить больше (можно даже 10000). После изменения номеров сообщений обмен должен начать проходить.
3. Ошибка преобразования данных XML.
На узле-отправителе проблемного сообщения откройте обработку ВыгрузкаЗагрузкаДанныхXML.epf (из состава конфигурации «Конвертация данных», находится в каталоге шаблона конфигурации после её установки), нажмите в самом низу кнопку «Недопустимые символы в плане обмена» и выберите узел-получатель. Если проверка выдаст ошибки, то вам достаточно будет устранить их непосредственно в указанных объектах и проблема будет решена.
Если же всё выше описанное не помогло решить проблему, то откройте XML файл сообщения (лучше всего открывать прямо в 1С:Предприятие 8) и посмотрите по указанному номеру строки, на каком объекте остановился прием. Теперь нужно в базе отправителе с помощью обработки «Регистрации изменений для обмена» найти данный объект и отменить по нему регистрацию, после чего обмен должен пройти. Последний способ является крайней мерой, если ничего остальное не помогло решить проблему, так как при этом проблемный объект не будет перенесен в базу приемника и ситуация может повториться при повторной регистрации проблемного объекта.