Обновление конфигураций 1С, работающих в режиме распределенной информационной базы (РИБ), часто превращается в настоящий квест для системного администратора или программиста. Особенно остро проблема встает при использовании механизма патчей (автоматически устанавливаемых расширений), которые критически важны для работы современных версий «1С:Розница 2.3». Многие коллеги сталкиваются с ситуацией, когда после стандартного обновления центрального узла и передачи данных в магазины, периферийные базы натыкаются на ошибку состава расширений и уходят в бесконечный цикл отката конфигурации. Проанализируем, почему это происходит, и разберем по шагам, как решить эту задачу эффективно.
Разберем техническую сторону вопроса. Механизм патчей в 1С реализован через расширения конфигурации. Когда мы обновляем центральную базу и накатываем патчи, система регистрирует изменения сразу в двух плоскостях: меняются метаданные основной конфигурации и меняется состав расширений. При выполнении обмена узел РИБ получает пакет, содержащий оба типа изменений.
Проблема заключается в том, что штатный механизм обновления в режиме «1С:Предприятие» не всегда может корректно обработать одновременное изменение основной конфигурации и состава патчей. Система видит, что структура расширений изменилась, и требует перезапуска, но в то же время она не может завершить обновление основной конфигурации базы данных. Происходит конфликт приоритетов, который приводит к откату изменений до исходного состояния. Рассмотрим подробнее, как выйти из этого замкнутого круга.
Если узлов в сети немного, можно воспользоваться проверенным алгоритмом, который позволяет принудительно «протолкнуть» обновление на периферийном узле. Разберем эту последовательность шагов:
Конфигуратор этого узла.F7). На этом этапе система применит изменения метаданных, включая те, что связаны с патчами.Библиотеки стандартных подсистем (БСП) проходят штатно, и кассы (РМК) начинают работать с учетом установленных патчей.Когда количество магазинов исчисляется десятками, ручной обход каждого конфигуратора становится невозможным. Проанализируем ситуацию: нам нужно автоматизировать действия, описанные в первом варианте. Для этого мы можем создать .bat или .cmd файл, который будет последовательно запускать нужные команды. Рассмотрим пример параметров запуска:
Сначала выполним принудительное обновление конфигурации базы данных без участия пользователя:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "ПутьКВашейБазе" /N "Админ" /P "Пароль" /UpdateDBCfg /Out "log.txt"
Затем запустим сеанс предприятия для выполнения обработок обновления БСП:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F "ПутьКВашейБазе" /N "Админ" /P "Пароль" /C "ЗавершитьРаботуСистемы" /Visible
Параметр /C "ЗавершитьРаботуСистемы" в связке с кодом в модуле управляемого приложения (если это предусмотрено вашей доработкой или БСП) позволит программе закрыться автоматически после выполнения фоновых задач обновления. Если же используется стандартная логика, рекомендуется применять специализированные загрузчики, которые отслеживают статус выполнения регламентных заданий обновления.
Исследуя проблему, нельзя игнорировать версию платформы. В версиях ниже 8.3.15.1985 механизмы работы с расширениями в РИБ были менее стабильными. Проанализируем опыт внедрений: начиная с версий платформы 8.3.18 и выше, компания «1С» внесла значительные исправления в логику синхронизации метаданных расширений. Если ваша конфигурация позволяет выполнить апгрейд платформы, это может решить проблему «откатов» конфигурации на корню, так как новые версии умеют корректно разделять этапы применения патчей и основных данных в одном сеансе обмена.
Посмотрим на ситуацию со стороны эксплуатации файловых баз. При частом обновлении конфигурации через РИБ (особенно с патчами) многие пользователи замечают аномальный рост файла 1Cv8.1cd. База может «распухнуть» с 4 Гб до 12-16 Гб без значительного прироста фактических данных. Это происходит потому, что при записи новых таблиц старые страницы файла помечаются как свободные, но физически из файла не удаляются.
Для решения этой проблемы при каждом обновлении необходимо выполнять регламентное обслуживание:
bin установленной платформы) с установленной галочкой «Исправлять обнаруженные ошибки».Это критически важно для производительности кассовых узлов, так как огромный файл базы данных существенно замедляет работу дисковой подсистемы, даже если данных внутри немного.
Иногда даже после успешного применения патчей в конфигураторе, «1С:Предприятие» продолжает выдавать ошибки при запуске. Это часто связано с локальным кэшем метаданных. В случае с РИБ и патчами, старые версии расширений могут «застрять» в папке пользователя. Проанализируем путь к этим файлам:
%LOCALAPPDATA%\1C\1cv8\
При возникновении странного поведения после обновления (например, когда патч применен, но его код не отрабатывает), рекомендуется полностью очистить содержимое этой папки. При следующем запуске система заново сформирует кэш на основе актуальной конфигурации базы данных и подключенных патчей.
Подведем итог нашему анализу. Чтобы обновление «1С:Розница» с патчами в РИБ проходило максимально безболезненно, рекомендуем придерживаться следующей стратегии:
UpdateDBCfg.Используя эти методы, вы сможете минимизировать время простоя кассовых узлов и обеспечите стабильную работу торгового оборудования, которая так сильно зависит от своевременной установки патчей в современных конфигурациях.