В практике администраторов и программистов 1С часто встречается коварная ситуация: после внесения изменений в конфигурацию и выполнения обновления часть пользователей видит новые формы и отчеты, а часть — продолжает работать в старой версии. Ситуация осложняется тем, что даже в Конфигураторе под тем же пользователем может отображаться актуальный код, а в режиме «Предприятие» — устаревшие данные. Разберем детально, почему это происходит, как оперативно исправить ситуацию и как построить работу так, чтобы избежать таких «глюков» в будущем.
Проанализируем ситуацию: основным виновником «разнобоя» версий является механизм, который в среде разработчиков иронично называют «демоническим обновлением» — это динамическое обновление конфигурации базы данных. Когда мы вносим изменения «на лету», не выгоняя пользователей из системы, 1С создает в таблице Config новую версию метаданных, но не заменяет основную. Пользователи, которые уже находятся в системе, получают уведомление о необходимости перезагрузки, но технически их локальный кэш может конфликтовать с новыми записями в базе данных.
Рассмотрим подробнее, что происходит «под капотом»: клиентское приложение 1С кэширует структуру метаданных (формы, модули, макеты) на локальном компьютере пользователя для ускорения работы. При динамическом обновлении этот кэш часто не обновляется корректно или обновляется частично. В результате возникает «рассинхрон»: ядро системы считает, что используется одна версия, а интерфейсные формы подтягиваются из старого локального кэша.
Выясним самый простой способ заставить 1С перечитать метаданные. Для этого в настройках запуска информационной базы можно прописать специальный параметр. Посмотрим на последовательность действий:
/ClearCache.Этот параметр заставляет систему при запуске игнорировать часть локального кэша метаданных. Однако стоит учитывать, что этот метод не всегда эффективен на 100%, так как он очищает только кэш запросов и некоторых форм, но может не затронуть глобальный кэш конфигурации.
Если параметр /ClearCache не помог, перейдем к более радикальным, но эффективным мерам. Нам необходимо полностью удалить папки, в которых 1С хранит временные данные конфигурации. Эти папки имеют длинные буквенно-цифровые названия (GUID).
Разберем, где находятся эти данные. Обычно это два пути:
%AppData%\1C\1Cv8\%LocalAppData%\1C\1Cv8\Для автоматизации этого процесса удобно использовать BAT-файл. Рассмотрим пример кода такого скрипта, который можно разослать пользователям или запускать централизованно:
@echo off
taskkill /f /im 1cv8.exe
taskkill /f /im 1cv8c.exe
rd /s /q "%AppData%\1C\1Cv8"
rd /s /q "%LocalAppData%\1C\1Cv8"
echo Кэш успешно очищен. Запустите 1С.
pause
Важный момент: после выполнения такого скрипта пользователям придется заново вводить свои логины в окне выбора базы (если они не были сохранены) и настраивать некоторые параметры интерфейса, так как удаляются и пользовательские настройки расположения окон.
Ситуация, описанная в сообщении 20, когда даже чистка кэша не помогла, указывает на еще одну проблему — «залипшие» настройки форм. 1С сохраняет состояние форм (видимость полей, положение колонок) в системных таблицах базы данных. Если в новой версии конфигурации вы кардинально изменили форму, старые настройки могут некорректно на нее накладываться.
Проанализируем ситуацию: чтобы не удалять пользователя полностью, попробуем очистить его настройки через интерфейс программы. В управляемых формах это делается следующим образом:
Это позволит сохранить учетную запись пользователя, но «сбросит» отображение формы к тому виду, который заложен в актуальной конфигурации.
Чтобы навсегда забыть о проблемах динамического обновления, разберем методологию «Семь раз отмерь — один отрежь», предложенную опытными разработчиками. Рассмотрим идеальный цикл внесения изменений:
Если вы все же вынуждены использовать динамическое обновление (например, для срочного исправления критической ошибки), обязательно после этого запланируйте «честное» обновление при первой же возможности. Это «прошьет» метаданные во все таблицы корректно.
В редких случаях из-за частых динамических обновлений структура внутренних таблиц Config может повредиться настолько, что обычное обновление начинает выдавать ошибки. Посмотрим на способ «лечения» такой базы:
.dt..dt в эту новую пустую базу.Этот процесс полностью пересоздает структуру таблиц и индексов, очищая базу от «мусорных» записей, которые могли остаться после неудачных динамических попыток обновления. В большинстве случаев это решает самые загадочные проблемы с поведением конфигурации у пользователей.
Подведем итог: стабильная работа пользователей обеспечивается не только знанием кода, но и строгим соблюдением регламентов обновления. Чистка кэша — это борьба с симптомами, а отказ от динамических обновлений и использование хранилища — это устранение самой причины болезни системы.