При сопровождении типовых конфигураций 1С (таких как «Бухгалтерия предприятия», «Зарплата и управление персоналом» или ERP) специалисты часто сталкиваются с накоплением большого количества расширений с префиксом EF_. Это так называемые патчи — оперативные исправления ошибок, которые фирма «1С» выпускает между релизами. Со временем их количество может исчисляться десятками, что вызывает резонный вопрос: как правильно контролировать этот «зоопарк» и когда их следует удалять, чтобы не нарушить стабильность системы при очередном обновлении?
В этой статье мы подробно разберем механизмы работы патчей, проанализируем официальные рекомендации вендора и выработаем надежный алгоритм действий при обновлении информационной базы.
Для начала проанализируем природу этих объектов. Патчи — это технические расширения конфигурации с типом Исправление (Correction). Они обладают наивысшим приоритетом применения. Основная цель патча — быстро исправить конкретную критическую ошибку в программном коде типового решения. Как только выходит следующий полноценный релиз конфигурации, в котором эта ошибка исправлена на уровне основной конфигурации, патч становится ненужным.
Рассмотрим стандартную логику системы: при запуске программы в режиме «1С:Предприятие» после обновления, система автоматически проверяет список установленных исправлений. Если идентификатор исправления в новом релизе совпадает с идентификатором патча, программа должна удалить его самостоятельно. Однако на практике этот механизм не всегда срабатывает идеально, что может привести к конфликтам.
Обратимся к официальной инструкции по обновлению, которая поставляется в файле 1cv8upd.htm. Фирма «1С» рекомендует выполнять ручную очистку списка исправлений перед началом процедуры обновления. Это позволяет избежать ошибок на этапе реструктуризации базы данных и исключает конфликты имен модулей.
Разберем по шагам алгоритм правильной подготовки, включая получение монопольного доступа к базе:
Ctrl+A) и нажмем кнопку Удалить.Важный момент: такие действия гарантируют, что при обновлении через Конфигуратор (с использованием файлов .cf или .cfu) никакое старое расширение не заблокирует процесс из-за ссылок на удаленные или измененные объекты метаданных.
Выясним причину, по которой опытные администраторы предпочитают ручное удаление, несмотря на наличие автоматики. Основная проблема заключается в возможной несовместимости структуры. Представим ситуацию: патч EF_001 вносит изменения в процедуру или заимствованную форму, которая в новом релизе была полностью переименована или перемещена в другой общий модуль. Если патч не будет удален до обновления метаданных, при первом запуске после обновления система может выдать критическую ошибку «Ошибка инициализации модуля», так как расширение попытается обратиться к несуществующей точке входа. В таких случаях полезен анализ состава расширений на наличие ошибок.
Также проанализируем ситуацию с «красными» патчами. В окне управления исправлениями они подсвечиваются красным цветом. Это означает, что возник конфликт: патч не может быть применен к текущему релизу. Такие объекты следует удалять немедленно, так как они не приносят пользы и только замедляют запуск системы.
Если в базе накопилось слишком много патчей и заходить в режим «Предприятие» неудобно (или база вовсе не открывается из-за ошибок), мы можем воспользоваться инструментами Конфигуратора. Рассмотрим, как это сделать максимально эффективно.
В окне Конфигурация — Расширения конфигурации можно вручную удалить все объекты, чье имя начинается на EF_. Если же нам требуется автоматизировать этот процесс для большого количества баз, воспользуемся возможностями командной строки — для этой задачи есть инструмент массового обновления конфигураций и баз.
Например, для полной очистки всех расширений (включая патчи) можно использовать следующий параметр запуска:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\Bases\MyBase" /N "Admin" /P "Pass" /DeleteCfg -AllExtensions
Будьте осторожны: параметр -AllExtensions удалит абсолютно все расширения, включая ваши собственные доработки. Если вам нужно удалить только патчи, лучше делать это выборочно через интерфейс или использовать специализированные скрипты, которые обращаются к конкретным именам расширений.
После того как обновление основной конфигурации успешно завершено, нам необходимо вернуть актуальные исправления, так как в новом релизе могли появиться новые ошибки. Рассмотрим стандартный алгоритм действий после обновления:
EF_-файлы, которые действительно необходимы для данной версии конфигурации.Проанализировав различные подходы, мы можем сформулировать оптимальную стратегию работы с патчами:
1. При ручном обновлении через Конфигуратор: всегда удаляйте патчи вручную перед процедурой обновления. Это самый безопасный путь, исключающий технические сбои при реструктуризации.
2. При автоматическом обновлении через интерфейс программы: система, как правило, берет управление патчами на себя, но после завершения процесса рекомендуется зайти в список установленных исправлений и убедиться в отсутствии конфликтов (отсутствие красных значков).
3. Если база не запускается после обновления: первым делом проверьте список расширений в Конфигураторе. В 90% случаев проблема решается удалением устаревшего патча EF_, который конфликтует с новым кодом типовой конфигурации — для диагностики подойдёт инструмент отладки и поиска причин ошибок.
Соблюдение этого простого регламента позволит вам содержать информационную базу в чистоте и минимизировать время простоя системы при плановом обслуживании.