Динамическое обновление конфигурации 1С, часто называемое в среде разработчиков «демоническим», — это мощный, но коварный инструмент. Оно позволяет вносить изменения в работающую базу без выгона пользователей, но расплатой за это часто становятся необъяснимые глюки кэша. Одной из самых загадочных ситуаций является та, при которой в рамках одного сеанса Windows под разными пользователями 1С программа ведет себя по-разному: один видит обновленный функционал, а другой — старый. Разберем детально, почему это происходит и как с этим бороться.
Рассмотрим стандартную ситуацию. Разработчик добавил новый пункт в меню расшифровки отчета. После проведения динамического обновления на продуктовой базе выясняется, что у конкретного пользователя Windows изменения не отображаются. Однако, если зайти в 1С под учетной записью администратора (или другого пользователя 1С) на этом же самом компьютере, новый пункт меню появляется. Это вводит в ступор, так как принято считать, что кэш привязан к пути информационной базы в профиле пользователя операционной системы.
Выясним причину такого поведения. Нам необходимо понять, как 1С физически хранит данные конфигурации на клиентской машине. Проанализируем структуру каталогов AppData\Local\1C\1Cv8 и AppData\Roaming\1C\1Cv8. Внутри мы видим папки с длинными идентификаторами (GUID). Многие ошибочно полагают, что на этом сегментация заканчивается, но это не так.
Важно понимать, что кэш не является единым монолитом для всей программы. Платформа 1С разделяет кэшируемые данные по нескольким уровням:
Рассмотрим подробнее момент динамического обновления. В момент, когда выполняется команда «Обновить конфигурацию базы данных», в SQL-таблице Config фиксируется новое состояние. Однако пользователи, которые уже находятся в системе (например, User1), продолжают работать со старой версией, загруженной в их оперативную память и локальный кэш. Для них платформа строит «виртуальное» представление метаданных, которое игнорирует изменения, чтобы избежать аварийного завершения сеанса.
Если в этот момент (или сразу после) мы заходим под другим пользователем (например, Admin), для которого сеанс еще не был инициализирован старой версией метаданных, платформа может создать для него новую ветку кэша или обновить существующую, подтянув актуальные данные. Таким образом, под одним пользователем Windows в папке с GUID базы могут сосуществовать разные наборы кэшированных объектов для разных учетных записей 1С.
Проанализируем структуру папок дальше. Внутри каталога кэша часто встречается папка vrs-cache. Это хранилище ресурсов веб-сервисов и описаний интерфейса. Именно здесь часто «застревают» описания форм и меню. Когда мы программно меняем состав меню в модуле формы, платформа должна перегенерировать описание этой формы. При динамическом обновлении механизм проверки актуальности этого кэша может дать сбой.
Посмотрим на пример того, как система определяет необходимость обновления. 1С сравнивает версию конфигурации в кэше с версией в базе данных. Но при динамическом обновлении версия базы данных меняется «мягко». Если сеанс User1 был активен, маркер версии в его локальных файлах может остаться старым, и система будет считать, что кэш все еще актуален, хотя на сервере уже лежат новые объекты.
Поскольку мы выяснили, что проблема кроется в глубокой сегментации кэша, стандартные методы не всегда помогают. Разберем по шагам наиболее эффективные способы решения:
1. Метод «Удалить-Добавить»
Самый надежный способ, который упоминался в обсуждении. При удалении базы из списка и её повторном добавлении, 1С генерирует для этой базы новый GUID. Программа начинает записывать данные в абсолютно новую папку, и старый, битый кэш просто перестает использоваться. Это гарантирует 100% результат, так как исключает обращение к старым сеансовым данным.
2. Ручная очистка каталогов
Рассмотрим, какие папки нужно удалять. Необходимо закрыть все сеансы 1С и очистить содержимое следующих каталогов:
%USERPROFILE%\AppData\Local\1C\1Cv8%USERPROFILE%\AppData\Roaming\1C\1Cv8Важно: удалять нужно не сами папки 1Cv8, а папки с GUID внутри них, чтобы не сбросить общие настройки платформы.
3. Использование параметра /ClearCache
Этот параметр командной строки можно добавить в дополнительные параметры запуска базы:
/ClearCache
Однако стоит помнить, что он очищает только кэш запросов и некоторые данные форм. Против серьезных проблем динамического обновления он часто оказывается беспомощен, так как не затрагивает основные файлы метаданных.
Для того чтобы «спать спокойно», как выразился автор темы, рекомендуем придерживаться следующих правил при выполнении обновлений:
Тестирование и исправление с единственным пунктом Проверка ссылочной целостности (это заставит сервер обновить внутренние таблицы метаданных).
@echo off
taskkill /f /im 1cv8.exe
taskkill /f /im 1cv8c.exe
rd /s /q "%LocalAppData%\1C\1Cv8"
rd /s /q "%AppData%\1C\1Cv8"
echo Кэш очищен. Запускайте 1С.
pause
Подводя итог, ответим на главный вопрос автора: почему под админом всё работало? Скорее всего, под учетной записью администратора вход в базу был выполнен после того, как динамическое обновление полностью завершилось и серверные процессы «переварили» новую версию. Для нового пользователя 1С (даже под тем же Windows-аккаунтом) платформа создала чистый контекст, в который сразу попали обновленные данные. Старый же пользователь «завис» в своей ветке кэша, которая была инициализирована еще до или в процессе обновления.
Таким образом, мы видим, что архитектура кэширования 1С гораздо сложнее, чем простая привязка к папке пользователя. Она учитывает состояние сеанса, момент входа и внутренние маркеры версий, что и приводит к подобным коллизиям при динамических обновлениях.