← На главную

Мы часто сталкиваемся с ситуацией, когда скорость внесения изменений в конфигурацию является приоритетом. Динамическое обновление («демоническое», как его часто называют в профессиональной среде) позволяет не выгонять пользователей из базы. Однако этот механизм таит в себе множество подводных камней. Рассмотрим проблему, с которой столкнулся автор темы: база обновляется динамически, все работает штатно, но в какой-то момент один конкретный пользователь перестает получать обновленную конфигурацию. Чистка локального кэша не помогает. Давайте разберем эту ситуацию детально, проанализируем механизмы работы платформы и найдем пути решения.

Механизм проблемы: почему это происходит?

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

1. Новая конфигурация записывается в специальную таблицу базы данных ConfigSave.
2. В таблице параметров Params устанавливается флаг (запись), сигнализирующий о наличии обновления.
3. Сеансы пользователей периодически опрашивают сервер на предмет наличия обновлений. Получив сигнал, клиентское приложение должно подтянуть изменения.

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

Уровень 1: «Зомби»-сеансы на сервере приложений

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

В архитектуре «клиент-сервер» за выполнение кода отвечает рабочий процесс rphost. Иногда при некорректном завершении работы (сбой сети, «убитый» процесс 1cv8c.exe) сеанс в кластере серверов остается в статусе «Активен» или «Спящий». Этот сеанс удерживает контекст старой конфигурации.

Когда пользователь запускает 1С снова, платформа может попытаться использовать механизм Session Reuse (повторное использование сеанса) или просто не может корректно обновить контекст из-за блокировок старого сеанса.

Что нам нужно сделать:

1. Откроем консоль Администрирование серверов 1С Предприятия.
2. Перейдем в ветку Сеансы нашей информационной базы.
3. Найдем все сеансы проблемного пользователя. Обратим внимание, что их может быть несколько (включая фоновые задания, если они запускались от его имени).
4. Принудительно удалим эти сеансы (через контекстное меню «Удалить»).

После этого попросим пользователя зайти в базу заново. В 90% случаев это решает проблему, так как создается абсолютно новый сеанс, который принудительно считывает актуальную версию метаданных из ConfigSave.

Уровень 2: Серверный кэш метаданных

В теме справедливо заметили: «Кэш есть клиентский, а есть серверный». Если чистка папок Local и Roaming на компьютере пользователя не помогла, проблема может быть в кэше на стороне сервера приложений.

Сервер 1С кэширует скомпилированные модули и структуру метаданных для ускорения работы. При интенсивном динамическом обновлении механизм инвалидации (сброса) этого кэша может дать сбой. В результате сервер продолжает «отдавать» конкретному сеансу старый байт-код.

Как правильно очистить серверный кэш:

Самый надежный способ, предложенный в обсуждении, — перезапуск службы агента сервера. Давайте сделаем это пошагово:

1. Обязательно согласуйте технологический перерыв, так как это отключит всех пользователей.
2. Остановите службу Агент сервера 1С:Предприятия (в оснастке services.msc).
3. Хотя перезапуск сам по себе сбрасывает оперативную память процессов rphost, для гарантии иногда требуется очистка временных файлов кластера (папка srvinfo), но делать это нужно с осторожностью, чтобы не удалить журнал регистрации или настройки кластера. Обычно достаточно простого перезапуска службы.
4. Запустите службу снова.

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

Уровень 3: Рассинхронизация на уровне СУБД (Таблицы Config и ConfigSave)

Это наиболее коварная ситуация. Как мы упоминали, динамическое обновление работает через таблицу ConfigSave. Основная конфигурация хранится в Config.

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

Решение проблемы:

Единственный стопроцентный способ «вылечить» базу в таком состоянии — это заставить платформу объединить Config и ConfigSave. Для этого нам необходимо:

1. Выгнать всех пользователей из базы (монопольный режим).
2. Зайти в Конфигуратор.
3. Внести любое незначительное изменение (например, добавить пробел в комментарий модуля или изменить синоним объекта, а потом вернуть обратно). Это нужно, чтобы платформа увидела изменение конфигурации.
4. Выполнить нормальное (статическое) обновление конфигурации базы данных (F7).

В этот момент содержимое ConfigSave корректно переносится в Config, таблицы очищаются от временных данных динамического обновления, и все пользователи начинают работать с единой версией метаданных.

Уровень 4: Конфликт настроек пользователя

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

Если вход под другим пользователем работает нормально, попробуем очистить настройки проблемного пользователя:

1. Зайдем в режим 1С:Предприятие под администратором.
2. Перейдем в раздел Администрирование -> Настройки пользователей и прав.
3. Найдем обработку Очистка настроек пользователей (названия могут отличаться в зависимости от конфигурации, например, в БСП это «Настройки пользователей»).
4. Выберем нашего проблемного пользователя.
5. Очистим настройки внешнего вида форм, настройки отчетов и прочие сохраненные данные.

Это заставит платформу сформировать интерфейс заново на основе актуальных метаданных.

Дополнительные проверки: Кэш перемещаемых профилей (Roaming)

Автор упомянул: «В папках локал и роаминг?». Это важный момент. Если вы работаете в терминальной среде (RDP) с перемещаемыми профилями (Roaming Profiles), простого удаления папки может быть недостаточно. Windows может восстанавливать старую версию папки AppData\Roaming\1C\1cv8\... из центрального хранилища профиля при входе пользователя в систему.

Мы должны убедиться, что кэш удален окончательно. Пути, которые нужно чистить:

• %USERPROFILE%\AppData\Local\1C\1cv8\
• %USERPROFILE%\AppData\Roaming\1C\1cv8\

Внутри этих папок нас интересуют каталоги с длинными именами (UUID), соответствующие нашей базе. Если вы не уверены, какой именно каталог относится к базе, можно удалить все содержимое (это сбросит список баз в стартере, но гарантированно очистит кэш).

Резюме и рекомендации

Подводя итог обсуждения коллективного разума, выделим алгоритм действий при возникновении «странностей» с динамическим обновлением:

1. Удалить сеансы: Проверьте консоль сервера 1С на наличие зависших сеансов пользователя.
2. Очистить настройки: Сбросьте настройки форм пользователя в режиме Предприятия.
3. Перезапустить сервер: Если проблема массовая или п.1 не помог — перезапустите службу агента сервера 1С.
4. Отказаться от динамического обновления: Если ошибка повторяется, необходимо выполнить полное обновление конфигурации в монопольном режиме.

Как верно отметили в теме: «не делать динамическое обновление» — это лучший совет для стабильности системы. Если же без него не обойтись, будьте готовы к регулярному обслуживанию (перезагрузкам) сервера для профилактики подобных «фантомных» ошибок.