Ошибка чтения файла сообщения обмена конфигурация узла распределенной иб не соответствует ожидаемой
Распределенная информационная база (РИБ) используется для организации работы филиалов и подразделений, позволяя обмениваться информацией между ними. Технология обмена между базами достаточно надежна, но время от времени ломается и она.
Прочитав эту статью, вы:
- узнаете о причинах возникновения самой распространенной ошибки РИБ: Конфигурация узла распределенной ИБ не соответствует ожидаемой;
- Получите пошаговые инструкции решения проблемы.
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000". )
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
Конфигурация узла распределенной ИБ не соответствует ожидаемой. Приведен очередной способ устранения этой ошибки, возникший не в результате сбоев в работе оборудования или при обмене, а в результате обновления платформы 1С.
Затеял я переход своей РИБ (самописная конфигурация на базе одной из старых версий Управления Торговлей 10.3) на новую платформу 1С с 8.3.12.1685 на 8.3.15.1565. Новая платформа была установлена во всех узлах, базы нормально и без ошибок загрузились и все казалось бы закончилось удачно. Но при попытке произвести обмен с одной из периферийных баз выскочила ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой". Ошибка встречалась мне и ранее и решалась выгрузкой конфигурации из главного узла с последующей загрузкой в периферийную. Эта же процедура была проделана и в этот раз, однако к восстановлению обмена не привела. Был произведен для проверки обмен и с другими узлами. Результат - обмен не идет ни с одним из периферийных узлов РИБ. После отката на старую версию платформы я приступил к решению возникшей проблемы.
Поиски решения на просторах интернета в целом ничего не дали. Основной способ был известен мне и уже опробован. Подмена содержимого тега v8de:Digest2 , как и ожидалось работает только один раз для измененного файла с данными. Внесение незначительных изменений в конфигурацию главного узла и последующий перенос изменений в периферийный узел тоже ни к чему не привели. Некоторым помогла выгрузка конфигурации из периферийной базы с последующей загрузкой в главную, но тут возник вопрос, а из какой периферийной базы выгружать? Ключики то везде разные.
Выгрузка из главной базы платформа 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 была "отвязана" от главного узла и в неё были загружены файлы конфигурации из главной базы (конфигурация - Загрузить конфигурацию из файлов). Проведенное затем сравнение конфигурации периферийной базы и файла конфигурации, выгруженного из главной базы показало различие в некоторых элементах метаданных (некоторые картинки, макеты, помощь и т.п.).
Причины непонятны, скорее всего зарытые ошибки в конфигурации главной базы некорректно были выгружены в файлы. Для устранения этого в периферийную базу была опять загружена конфигурация из главного узла. После проведенных манипуляций обмен не восстановился:
Выгрузка из главной базы не изменилась и приведена выше.
Выгрузка из периферийной базы 1 платформа 8.3.15.1565:
Вспомнив о том, что многим помогала операция загрузки файла конфигурации из периферийной базы в главную, проделал абсолютно идиотскую операцию: загрузил в главную базу файл конфигурации, который был из нее же выгружен (ведь этот файл был только что загружен в периферийную базу). При анализе файла выгрузки из главной базы я с удивлением увидел появившийся блок с метаданными, т.е. произошло реальное изменение метаданных конфигурации (могу только предположить, что это наслоения багов старых динамических обновлений).
Этот файл выгрузки был уже нормально принят моей периферийной базой, причем обновления конфигурации периферийной базы не потребовалось, блок метаданных был молча принят периферийной базой.
После этого двухсторонний обмен восстановился:
Выгрузка из главной базы платформа 8.3.15.1565:
Выгрузка из периферийной базы 1 платформа 8.3.15.1565:
При восстановлении обмена с другими периферийными базами ( с теми у которых один ключ совпадал) я сделал попытку избавиться от этапа загрузки конфигурации из файлов, решив, что это лишнее. К сожалению ничего не получилось. Очевидно, первоначальная идея, что в этом наборе файлов содержится информация, не попадающая в файл конфигурации cf оказалась верной. На просторах интернета предлагается для восстановления обмена в РИБ вносить изменения в конфигурацию, приводящие к реконфигурации базы данных. Реконфигурация, конечно, очень полезна, а иногда даже необходима при смене платформы, но в данном случае она оказалась абсолютно бесполезной, на генерацию ключей и восстановление обмена она никакого влияния не оказала, это было проверено.
Итак окончательная последовательность действий при возникновении ошибки обмена данными в РИБ при переходе на другую, более свежую платформу 1С следующая:
- Снимаем резервные копии всех баз данных
- Устанавливаем новую платформу и далее все манипуляции производим, загружая базы данных под новой платформой
- Из главной базы РИБ выгружаем файл конфигурации cf. Это у нас будет эталонный файл конфигурации.
- Из главной базы выгружаем файлы конфигурации. Так как в системе есть ограничения на длину наименования файлов, папку для выгрузки выбираем как можно с коротким именем (у меня было C:\1). Эта папочка тоже будет эталонной.
- Отвязываем периферийную базу от главной базы. Обработку не привожу, она тривиальна и содержит 5 строк кода. Кто не сможет написать на коленке, в интернете полно предложений по этому вопросу.
- В режиме конфигуратора в периферийную базу загружаются файлы конфигурации из главного узла (конфигурация - загрузить конфигурацию из файлов). Конфигурацию НЕ сохраняем, конфигурацию базы данных НЕ обновляем.
- Загружаем конфигурацию ( cf файл) в периферийную базу (конфигурация - загрузить конфигурацию из файла).
- Сохраняем основную конфигурацию и обновляем конфигурацию базы данных периферийной базы данных.
- Привязываем периферийную базу к главной базе данных, предварительно закрыв конфигуратор.
- Повторяем пункты 5 - 9 для всех периферийных баз.
- Загружаем файл конфигурации главного узла в главный узел, ДА ВОТ ТАК ВОТ.
- Сохраняем основную конфигурацию и обновляем конфигурацию базы данных главной базы данных.
Далее, скрестив на всякий случай пальцы (с продуктами от 1С возможно все), пробуем сделать обмен в РИБ.
Обновление конфигурации в ПБ
Откройте конфигуратор ПБ и убедитесь, что блокировка на обновление снята и команда обновить конфигурацию доступна: меню Конфигурация — Поддержка — Обновить конфигурацию . Тем не менее обновить конфигурацию ПБ выгруженным файлом конфигурации ЦБ на актуальных конфигурациях 1С не получится, для этого снимем с поддержки конфигурацию ПБ, а потом вернем ее при загрузке файла конфигурации ЦБ: меню Конфигурация — Поддержка — Настройки поддержки — кнопка Снять с поддержки .
Загрузите файл конфигурации ЦБ: меню Конфигурация — Загрузить конфигурацию из файла .
Примите обновление конфигурации по кнопке F7.
Главный результат операции в сопоставлении редакций ЦБ и ПФ. Они должны быть одинаковыми. Проверить после обновления редакцию ПБ можно по меню Справка — О программе .
Похожие публикации
(3 оценок, среднее: 5,00 из 5)
Публикацию можно обсудить в комментариях ниже.
Обратите внимание!
В комментариях наши эксперты не отвечают на вопросы по программам 1С и законодательству.
Задать вопрос нашим специалистам можно в Личном кабинете
После обмена данными из 12 баз была получена информация только от 10.
1 периферийная база не обновилась и от одной уже центральный узел не мог получить данные, хотя сама база обновилась.
А что было? А было динамическое обновление.
Внести МОНОПОЛЬНО какое-то изменение в центральную базу (можно поставить пробел в любом месте) и сохранить базу. Выгрузить cf и загрузить во все периферийные базы, сделать монопольно обмен и монопольно обмен в центральной.
1. Выгрузить из главной базы конфигурацию: Зайти в конфигуратор, пункт "Конфигурация", "Выгрузить в файл" и переписать конфигурацию в филиал.
2. Закрыть в филиале все сессии 1С и открыть в режиме Предприятие под полными правами обработку "УстановитьГлавныйУзел", ничего не выбирая, нажать кнопку "Выполнить".
3. Запустить Конфигуратор, пункт "Конфигурация", "Загрузить конфигурацию из файла", после загрузки нажать сохранить (дискетка) и нажать F7 (Обновить)
4. Снова открыть в режиме Предприятие под полными правами обработку "УстановитьГлавныйУзел", выбрать центральный узел и нажать кнопку "Выполнить".
5. Сделать обмен в этой базе, после чего выполнить обмен в центральной. Все изменения должны загрузиться.
P.S. Через неделю еще у одного клиента возникла та же проблема. Решение помогло.
Корректировка файлов обмена РИБ
Если указанные выше действия не помогли и обмен проходит с ошибками — переходим к корректировке файлов обмена РИБ. При этом все действия по сопоставлению конфигураций ЦБ и ПБ, что рассмотрены выше, должны быть выполнены.
- выгрузка файла обмена из периферийной базы;
- выгрузка файла обмена из центральной базы;
- корректировка файла обмена из ЦБ;
- загрузка скорректированного файла;
- перезапись файла обмена из ПБ;
- проверка исправлений.
Настройка центральной базы
Настройка РИБ выполняется в разделе Администрирование — Настройки программы —Синхронизация данных — ссылка Настройка синхронизации данных — кнопка Новая синхронизация данных — ссылка Распределенная информационная база .
Перед началом настройки выставляется префикс основной базы, например, ЦБ. PDF
Настройка центральной базы РИБ выполняется по этапам:
Настройка выполняется в автоматическом режиме Мастером настройки синхронизации , от пользователя требуется следовать указаниям Мастера и нажимать кнопку Далее .
Результат выполненной настройки в центральной базе.
Настройка периферийной базы
После настройки центральной базы необходимо настроить периферийную базу. Для этого добавьте созданную периферийную базу в список задач 1С. PDF При открытии периферийной базы будет автоматически открыто окно настройки синхронизации.
Настройка периферийной базы РИБ выполняется по этапам:
- настройка параметров подключения; PDF
- настройка правил отправки и получения данных.
Настройка выполняется Мастером настройки автоматически. Для настройки Сценария синхронизации нажмите кнопку Добавить и все правила будут созданы по умолчанию. PDF
Следуя шагам Мастера, завершите настройку.
Результат настройки периферийной базы.
После завершения настройки в периферийной базе проверьте наличие перенесенных данных из центральной базы:
- настройки программы;
- справочники;
- документы;
Все данные должны присутствовать. Пример перенесенных поступлений. PDF
Специальные предложения
Тоже была такая проблема. Решение полностью рабочее.
Но мы к сожалению не смогли определить причину возникновения этой ошибки. Она у нас появлялась и при отсутствии динамических обновлений.
Поэтому мы сделали следующее. Все изменения, которые хотим внести, собираются в отдельной копии сотрудниками отдела. А потом разом переносятся в главный узел через сравнение и объединение. Ну а потом уже обновление. Логика в том, что бы не нажимать на кнопку сохранить(дискета) в главной узле более одного раза. Такое чувство, что ошибка кроется там.
(1) ЭЭЭЭЭЭ.
Хранилищем не пробовали пользоваться. всеми сотрудниками отдела из 20 человек работаем уже 5 лет с одной базой ,
никаких проблем нет и не было ни когда ) Центральная база накатывается из хранилища, потом идут обмены со всеми.
Ну разве , что само хранилище падает раз в год!) Но это ни на, что не влияет ни на наши копии ни на рабочие базы.
Создаем новое и понеслась.
Да согласен решение рабочее,можно даже ещё проще делать, у меня 21 узел. и к сожалению такое часто бывает. 1-2 узел стабильно "заболевает". Принято решение добавлять реквизиты максимум 1 раз в неделю и обновляться динамически не чаще 1 го раза в день. Не уверен что проблема в кнопке "сохранить". Это скорее проблема динамического обновления. Мы используем хранилище конфигураций, там кнопка "сохранить" в принципе не работает.
К сожалению, Ответа на вопрос: "Как делать так, что бы базы не "заболевали"?" -мы так и не нашли, И не даёт ответ на этот вопрос данная статья!
Заметил такую особенность, что если платформа главного узла и подчиненного отличается, то данная ситуация происходит намного чаще.
Вместо обработки "УстановитьГлавныйУзел" можно использовать параметр запуска конфигуратора ResetMasterNode - помогает когда после неудачного обновления не получается войти в режиме предприятия.
Внимание! После платформы 8.3.4.1860 ResetMasterNode перестал работать, а разработчики никак не починят. Поэтому используйте старые версии платформы если в текущей не отстегнулось.
И еще из личного опыта:
Не всегда удается загрузить cf в подчиненный узел. Т.е. он загружается, но в файле обмена все равно присутсвует старый идентификатор версии конфигурации. Либо головная база "теряет" у себя этот идентификатор. И после того как вгрузили cf - ничего не работает.
В этом случае помогает чистка кеша.
Для файловой базы в папке с базой оставляем единственный файл 1Cv8.1CD (не забываем делать копии. ) и при запуске 1С в окне выбора баз удаляем и заново создаем строку подключения. Это помогает и для клиентов серверных баз.
-или-
Пользовательский кеш находится в C:\Users\Юзер\AppData\Roaming\1C\1cv8\ - каждая база в отдельной папке. Имена папок в виде гуидов, но разобраться вам поможет файл C:\Users\Юзер\AppData\Roaming\1C\1CEStart\ibases.v8i
Для серверной базы - удаляем из консоли администрирования (оставляем базу, без изменений) и создаем заново.
-или-
Серверный кеш находится на сервере в C:\Program Files\1cv8\srvinfo\reg_1541 - для каждой базы своя папка, изучите 1CV8Clst.lst. Остановить службу и вычистить содержимое нужной папки. Помним про копии.
Конфигурация узла распределенной ИБ не соответствует ожидаемой. Одна из самых популярных ошибок РИБ. Приведены стандартная методика устранения (уже публиковалась ранее) и расширенная (для сложных случаев).
Для начала привожу список используемых мной сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением. );
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда.
1. Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Самой распространенной ошибкой при использовании распределенных баз в 1с:Предприятие 8.x является ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой". Связана она с рассинхронизацией конфигурации главного и подчиненного узла, возникать может по нескольким причинам, самая распространенная из них это динамическое обновление конфигурации. Рассмотрим основные пути решения данной проблемы, укажу способы по простоте их использования, сначала самые простые (но иногда не менее эффективные), потом более сложные:
Отключение Главного узла периферийной базы
Данная методика неоднократно помогала нам решить проблему у клиентов при получении ошибки РИБ:
- Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Необходимо привести конфигурацию периферийной базы к ожидаемой, т.е. привести ее в соответствие с конфигурацией центрального узла. Казалось бы, чего проще! Выгрузить в файл конфигурации из центральной базы и загрузить его в периферийную. Но если мы откроем периферийную базу в Конфигураторе и попытаемся выгруженную конфигурацию центральной базы загрузить в периферийную, то увидим, что это не так просто сделать. Изменения заблокированы средствами управления РИБ.
При попытке обновить конфигурацию вручную команда Обновить конфигурацию недоступна.
Что делать? Рекомендуемая последовательность действий:
- выгрузка конфигурации центральной базы (ЦБ) в файл;
- открепление Главного узла в периферийной базе (ПБ);
- обновление конфигурации в периферийной базе (ПБ);
- закрепление Главного узла в периферийной базе (ПБ).
Выгрузка файла обмена из периферийной базы
Оставьте рабочим только выполняемое действие настройки Отправка данных , используя кнопку Настроить — Сценарии синхронизации — кнопка Включить/Отключить .
Выполните обмен с центральной базой по кнопке Выполнить сценарий .
Обновление конфигурации центральной базы
В том случае, если периферийная база изменения получила, но еще не применила, а в центральной базе в этот промежуток вносятся изменения еще раз и снова инициируют обмен, то возникает конфликт.
Центральная база ожидает увидеть в периферийном узле предыдущие изменения и попытается обновить ее на новые, а по факту конфигурация периферийной базы еще не обновлена.
Проверка обмена в центральной базой
Выполняем Получение данных в центральной базе. Если все хорошо, в отчете отразится информация о том, что данные приняты и отправлены.
Выполняем несколько последовательных обменов для проверки. Если все хорошо, в периферийной базе «красная точка» по получению данных из отчета исчезнет.
Да, все отлично. Обмен восстановлен, ошибка исправлена.
Работа с ошибками РИБ относится к разряду профессиональных и Бухэксперт8 рекомендует передавать их для исправления специалистам 1С. При работе с ошибками обязательно копируйте базы данных.
Помогла статья?
Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно
Выгрузка конфигурации ЦБ в файл
Откройте Конфигуратор ЦБ и выгрузите конфигурацию в файл по кнопке Конфигурация — Сохранить конфигурацию в файл .
Этим файлом мы обновим конфигурацию ПБ после открепления в ней Главного узла обмена.
Обмен в РИБ
Для обмена периферийной базы с центральной нажмите кнопку Синхронизировать : раздел Администрирование — Настройки программы — Синхронизация данных — ссылка Настройки синхронизации данных .
Будет выполнен обмен с центральной базой.
По окончанию операции данные периферийной базы будут выгружены в центральную базу, а данные центральной базы загружены в периферийную с помощью РИБ.
Аналогичные правила для центральной базы.
После того, как вы создали РИБ, все изменения в конфигурацию информационной базы можно вносить только в главном узле центральной базы. При обновлении конфигурации центрального узла будут переданы в подчиненные узлы и автоматически применены там.
Динамическое обновление
- Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Это предотвращает в большинстве случаев появление ошибки рассогласования конфигураций центральной и периферийных баз.
Но если по каким-то причинам ошибка все-таки имеет место — проблему нужно решать.
Перед исправлением ошибки обязательно сделайте копии центральной и периферийных баз данных. Иначе вернуться к исходному варианту после неудачной попытки исправления вы не сможете.
Распределенная информационная база (РИБ)
Создание и настройка распределенной базы данных (РИБ) необходимы в случаях, когда нет возможности работать пользователям из разных мест с одной базой. Это возможно при работе с филиалами и подразделениями организации, которые территориально располагаются в разных местах, но должны обмениваться информацией с центральным офисом. Или если по принятым мерам безопасности в организациях ограничен доступ в интернет и удаленно подключиться к рабочей базе, например, через RDP нет возможности.
В этих случаях выполняют настройку распределенной информационной базы.
Базу центрального офиса, где собираются все данные, называют центральной, а базы филиалов — периферийными.
Рассмотрим создание РИБ на примере 1С:Бухгалтерия 3.0.
Загрузка скорректированного файла
Конфигуратор при получении данных должен быть закрыт.
После этого делаем Отправку данных и переходим в центральную базу.
Не денамическое обновление корневого узла.
- Данный метод обноружил случайно, на просторах интернета такого способа не нашел, но помогает он очень часто и в отличии от следующих способов помогает решить проблему намного быстрее и проще. Заключается он в том, что мы еще раз меняем что либо в корне конфигурации (я чаще всего меняю синоним конфигурации, например добаляя пробел в конце синонима) и делаем при этом не динамическое обновление. После этого производим еще раз обмен из главного узла с подчиненными. В большенстве случаев, хотя и не всегда к сожалению, данный метод позволяет решить ошибку рассинхронизации конфигураций. Этот способ не всегда является эффективным, но в отличии от следующих способов позволяет быстро решить данную проблему, особенно при большом количестве узлов распределенных баз.
3. Ошибка преобразования данных XML.
Корректировка файла обмена из ЦБ
В файле обмена из ЦБ замените блок, содержащий информацию об изменениях конфигурации на блок из файла ПБ.
Файлы обмена находятся в папке, которую указали при настройке обмена синхронизации распределенных баз. Всего там находятся два файла:
- Файл выгрузки из периферийной базы: Message_ФЛ_ЦБ.
- Файл выгрузки из центральной базы: Message_ЦБ_ФЛ.
Откройте файл обмена Message_ЦБ_ФЛ, редактором позволяющим редактировать xml-файлы, например, Блокнот.
Блок файла Message_ЦБ_ФЛ.
Блок файла Message_ФЛ_ЦБ.
Перечисленные действия необходимо выполнять очень внимательно. Неправильное копирование может повлечь неработоспособность РИБ. Поэтому создание резервных копий перед этим шагом обязательно.
После замены информации сохраните изменения в файле Message_ЦБ_ФЛ.
Выгрузка файла обмена из центральной базы
Оставьте рабочим только выполняемое действие настройки Отправка данных , используя кнопку Настроить — Сценарии синхронизации — кнопка Включить/Отключить .
Выполните отправку данных из центральной базы по кнопке Выполнить сценарий .
Подмена хэша конфигурации в файле обмена.
- Данный метод был взят из статьи Популярные ошибки РИБ. Метод на мой взгляд довольно таки сложный и длительный, поэтому я его указываю как самый последний из вариантов решения данной проблемы, его стоит использовать только лишь в том случае, если не один из выше перечисленных способов не позволил решить проблему. Его суть заключается в том, что мы заменяем хеш конфигурации в файле обмена на правильный и тем самым обманывая программу производим обмен.
Последовательность действий:
- выполняем действия из предыдущей методики;
- выгружаем из переферийной базы файл обмена, но не загружаем его в главную базу;
- выгружаем из главной базы файл обмена, но не загружаем его в переферийную базу;
- в файле обмена из главной базы заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла переферийной базы (пример см. ниже).
- производим загрузку файла из 4-го пункта в переферийную базу;
- обязательно перезаписываем файл обмена из переферийной базы (2-й пункт) этот файл не должен быть загружен при обмене в главную базу.
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из главной базы:
нужно заменить на блок файла обмена из переферийной базы (обратите внимание Digest1 у файла из переферийной базы всегда равен "00000000000000000000000000000000". )
Чистка кэша .
- При работе в режиме предприятия 1с кэширует метаданные для ускорения работы программы и при динамическом обновлении конфигурации использует их до момента перезапуска сеанса пользователя. При это могут возникать ситуации, когда после перезапуска программа не обновила метаданные из измененной, а продолжает использовать старые. В такой ситуации помогает очистка кэша, при новом запуске программа обновит метаданные. Очистить кэш можно множеством способов, приведу несколько из них:
- На мой взгляд самый простой из них это удаление базы из списка информационных баз и добавление заново под другим именем. При добавлении базы как новой в список информационных баз программа создаст новый каталог на диски для хранения кэшей к этой базе.
- Можно очистить базу удалив папки с кэшем. Папки храняться в зависимости от версии windows:
\Local Settings\Application Data\1C\1Cv82
Можно воспользоваться готовым bat-файлом для удаление файлов кэша, как это описано в этой статье "Чистка кэша 1с".
Перенос конфигурации в распределенный узел .
Самый распространенный способ решения данной проблемы, он почти в 100% случаев помогает решить данную проблему, опять таки замечу, что почти в 100%, т.к. у меня возникали случаи, когда переносом конфигурации из главного узла в подчиненный проблема не решалась. Данный метод заключается в переносе конфигурации из главной базы в распределенную.
Последовательность действий:
- выгружаем из центральной базы конфигурацию в cf-файл;
- отвязываем переферийную базу от главного узла, вызвав команду:
- заменяем конфигурацию переферийной базы на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла".
- Привязываем переферийную базу обратно к главному узлу РИБ, вызвав команду:
где в качестве параметра передаем главный узел распределенной базы.
Для выполнение этих действий удобнее всего воспользоваться обработкой, которую можно скачать здесь (подходит для всех конфигураций на не управляемых формах, т.к. Розница 1.0 или УТ 10.3, огромное множество аналогичных можно найти на просторах инфостарта).
Подключение Главного узла в ПБ
Откройте ПБ в пользовательском режиме. На актуальных релизах 1С программа автоматически видит отключенный Главный узел и предлагает его восстановить. Нажимаете кнопку Восстановить .
Программа выполнит автоматическое обновление базы данных.
Если программа 1С не предлагает автоматически восстановить подключение к Главному узлу или по каким-то причинам она проходит с ошибками, запустите внешнюю обработку Главный узел : кнопка Главное меню — Файл — Открыть . Запуск выполняется пользователем с Полными правами или возможностью работать с внешними отчетами и обработками.
В открывшейся форме в поле Главный узел базы укажите тип данных Полный.
Выберите из списка узлов главный, в нашем случае БУХЭКСПЕРТ, и нажмите кнопку Подключить Главный узел .
При подключении Главного узла Конфигуратор ПБ должен быть закрыт.
Выполните обмен сначала в ПБ, а после него в ЦБ. Все изменения должны загрузиться.
Причины возникновения ошибки
Если в момент обновления конфигурации база «падает» из-за отключения электропитания или медленно работает канал обмена, конфигурация главного узла успевает измениться. а периферийного — нет.
Причин, приводящих к подобной ошибке много, но наиболее частыми можно назвать:
- новое обновление центральной конфигурации до получения ответа о предыдущем обновлении периферийной конфигурации;
- динамическое обновление центральной конфигурации;
- отключение электропитания компьютера в момент обновления;
- и т.д.
Открепление Главного узла в ПБ
Чтобы обновить конфигурацию ПБ вручную потребуется снять блокировку обмена. Сделать это можно только открепив Главный узел обмена. К сожалению, ни встроенной обработкой изменения реквизитов, ни работой напрямую с константой Главной узел в пользовательском режиме этого сделать нельзя. Только через внешнюю обработку.
Код этой обработки невероятно прост, всего несколько строчек, и вы можете:
- самостоятельно сделать такую обработку по указанному коду; PDF
- скачать готовый вариант от БухЭксперт8.
Запустите обработку через Главное меню — Файл — Открыть .
Запуск выполняется пользователем с Полными правами или возможностью работать с внешними отчетами и обработками.
Будет открыта форма, указывающая на Главный узел ЦБ, в нашем случае БУХЭКСПЕРТ. Для отключения его нажмите на кнопку Отключить Главный узел .
При отключении Главного узла Конфигуратор ПБ должен быть закрыт.
Читайте также: