Почему пропадают изменения в 1С после динамического обновления и как это исправить?

При работе в 1С:Предприятие 8.3 (особенно начиная с релизов 8.3.10) разработчики часто сталкиваются с неприятным поведением системы: после выполнения динамического обновления (применения изменений конфигурации базы данных без выгона пользователей) внесенные доработки работают у пользователей, но в открытом сеансе Конфигуратора код или формы «откатываются» к прежнему состоянию. При запуске отладки изменения могут исчезнуть, а последующее сохранение модуля перезаписывает обновленную конфигурацию старыми данными.

Рассмотрим подробно причины возникновения этой проблемы, механизм работы кэша платформы и способы полного устранения данного сбоя.

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

Выясним внутренний механизм возникшей ошибки. При проведении динамического обновления платформа создаёт в служебных таблицах базы данных (в частности, Config и Params) дубликаты записей изменяемых объектов. Если сеанс Конфигуратора не закрывается после применения изменений, возникают следующие проблемы:

1. Рассинхронизация локального кэша сеанса: Конфигуратор продолжает удерживать в оперативной памяти и локальных папках кэша профиля пользователя старые хэши и структуры метаданных.
2. Откат при запуске отладки: При вызове режима отладки прямо из неперезапущенного Конфигуратора сервер и клиентское приложение считывают старое кешированное состояние. Если продолжить редактирование кода в этом же сеансе и повторно сохранить конфигурацию, устаревшие данные из памяти Конфигуратора перекрывают актуальные данные в СУБД.
3. Повреждение кэша клиент-серверных вызовов: Частое динамическое обновление приводит к некорректной адресации модулей в файлах кэша SICache и DBNameCache.

Способ 1. Соблюдение правильного регламента работы в Конфигураторе

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

1. Внесите необходимые изменения в объект (модуль, форму, макет).
2. Выполните обновление конфигурации базы данных (динамически).
3. Категорически обязательно закрыйте Конфигуратор сразу после обновления! Не продолжайте редактирование и не запускайте отладку из текущего сеанса.
4. Запустите Конфигуратор заново — только после этого кэш метаданных обновленного сеанса перечитается из СУБД корректно.

Способ 2. Очистка кэша клиента и применение ключа /ClearCache

Разберем настройку параметров запуска 1С для предотвращения разрастания и повреждения кэша метаданных. Платформа 1С позволяет принудительно очищать кэш клиент-серверных вызовов при каждом запуске приложения.

Для настройки ключа выполним следующие шаги:

1. Откройте окно запуска 1С:Предприятия.
2. Выберите нужную информационную базу и нажмите кнопку Изменить....
3. Нажмите кнопку Далее и перейдите на страницу дополнительных параметров запуска.
4. В поле Дополнительные параметры запуска укажите команду:

/ClearCache

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

Способ 3. Очистка временных файлов и кэша сервера 1С

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

Посмотрим на пример командного файла (bat/cmd), который останавливает службы кластера 1С, принудительно завершает процессы серверных рабочих процессов rphost.exe, удаляет файлы кэша сеансных данных snccntx* и временные профили *.pfl, после чего перезапускает службы:

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\Program Files\1cv8\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"

echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5

taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5

echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*

echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo start %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc start %SERVICE_1C_NAME%
sc start %SERVICE_RAS_NAME%
echo Service %SERVICE_1C_NAME% restarted at %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%

Важно: Перед запуском скрипта убедитесь, что пути к служебным папкам srvinfo и службам сервера соответствуют вашей версии платформы и разрядности системы.

Способ 4. Безопасная схема разработки и внесение изменений

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

1. Использование расширений конфигурации (файлы .cfe): Доработку логики программных модулей, печатных форм и отчетов рекомендуется выносить в расширения. Обновление расширений происходит на лету и не разрушает структуру таблиц Config в СУБД.
2. Подготовка обновления в хранилище или базе разработки: Изменения выполняются в тестовой базе, выгружаются в файл конфигурации (.cf), после чего файл накатывается на рабочую базу. Это снижает вероятность накопления промежуточных ошибок кэша.