← На главную

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

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

Выясняем причину: баг платформы 8.3.11

Рассмотрим ситуацию, с которой столкнулся автор темы. В центральной базе конфигурации «1С:Розница» были отредактированы несколько отчетов. При выгрузке пакета обмена в формате XML было замечено, что файл не содержит никакой информации об обновлении конфигурации. В нем отсутствовали служебные секции v8de:Version и v8md:Metadata, а также не изменились хэш-суммы конфигурации в тегах Digest1 и Digest2.

Причина такого поведения кроется в критической ошибке платформы линейки 8.3.11 (в частности, в релизе 8.3.11.2867). Суть бага заключается в следующем: если разработчик вносит изменения в объекты метаданных, которые не влияют на физическую структуру таблиц базы данных СУБД (модули объектов, формы, макеты, отчеты или обработки), платформа некорректно определяет необходимость выгрузки обновления. Механизм регистрации изменений конфигурации для РИБ просто «пропускает» эти правки, считая конфигурацию идентичной прежней версии. В результате периферийный узел применяет только файлы данных, а программный код остается старым.

Способ 1: Обновление платформы 1С (Основное решение)

Самым простым и правительным решением является обновление технологической платформы 1С:Предприятие на сервере и всех рабочих станциях. В линейке платформ 8.3.12 (начиная с релиза 8.3.12.1595) этот баг был полностью устранен.

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

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

Способ 2: Искусственная («фиктивная») реструктуризация базы данных

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

Разберем по шагам, как это сделать:

1. Откроем центральную базу в режиме Конфигуратор.
2. Создадим новый объект метаданных, который гарантированно меняет структуру таблиц СУБД. Проще всего добавить новую Константу (например, с именем ТехническоеОбновлениеРИБ и типом данных Булево) или добавить новый реквизит в любой неиспользуемый справочник.
3. Выполним обновление конфигурации базы данных, нажав клавишу F7 (или выбрав пункт меню «Конфигурация — Обновить конфигурацию базы данных»).
4. Запустим сеанс обмена данными.

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

Способ 3: Временное отключение узла от РИБ (Ручное обновление)

В случаях, когда обмен заблокирован или периферийная база категорически отказывается принимать обновления конфигурации стандартным путем, мы можем прибегнуть к методу «отвязки» подчиненного узла от главного с последующим ручным обновлением через файл конфигурации (.cf).

Проанализируем этот алгоритм:

1. Выгрузим файл конфигурации из центральной базы. Для этого в Конфигураторе ЦБ выберем «Конфигурация — Сохранить конфигурацию в файл...» и сохраним файл под именем 1cv8.cf.
2. Откроем Конфигуратор подчиненного узла. Обратите внимание, что в режиме РИБ конфигурация заблокирована для редактирования. Чтобы снять блокировку, нам нужно программно отключить связь с главным узлом.
3. Для этого откроем подчиненную базу в режиме «Предприятие» и выполним следующий код (например, через внешнюю обработку):
   Скопировать код

   
   // Программно отключаем признак подчиненности главному узлу
   ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
   

   Примечание: В современных версиях платформы (начиная с 8.3.20) эту операцию можно выполнить быстрее, запустив Конфигуратор подчиненного узла из командной строки с параметром /ResetMasterNode.
4. После выполнения кода подчиненный узел становится автономной базой. Закроем режим «Предприятие» и перейдем в Конфигуратор подчиненного узла. Теперь возможность редактирования конфигурации активна.
5. Выполним команду «Конфигурация — Загрузить конфигурацию из файла...» и выберем ранее сохраненный файл 1cv8.cf центральной базы.
6. Обновим конфигурацию базы данных по клавише F7.
7. Снова запустим подчиненную базу в режиме «Предприятие» и восстановим связь с главным узлом с помощью кода:
   Скопировать код

   
   // Находим ссылку на главный узел в плане обмена
   СсылкаНаГлавныйУзел = ПланыОбмена.ПоМагазинам.НайтиПоКоду("ЦБ"); 
   
   Если ЗначениеЗаполнено(СсылкаНаГлавныйУзел) Тогда
       // Восстанавливаем связь
       ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);
       Сообщить("Связь с главным узлом успешно восстановлена.");
   Иначе
       Сообщить("Не удалось найти предопределенный главный узел!");
   КонецЕсли;
   

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

Способ 4: Ручной сброс локального кэша

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

При любых подозрениях на некорректное отображение интерфейса после обмена РИБ рекомендуется выполнить следующие действия:

• Добавить в параметры запуска информационной базы в окне запуска 1С команду /ClearCache.
• Или вручную удалить папки локального кэша, которые находятся по путям:
  %userprofile%\AppData\Local\1C\1cv8
%userprofile%\AppData\Roaming\1C\1cv8

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