Каждый разработчик 1С рано или поздно сталкивается с мистической ситуацией: изменения в конфигураторе внесены, база обновлена, под учетной записью программиста все работает идеально, но рядовые пользователи продолжают видеть старые формы или, что еще хуже, система исполняет старый код, который уже был удален или закомментирован. Особенно остро эта проблема проявляется в файловых базах, развернутых на терминальных серверах (RDP).
В этой статье мы подробно разберем, почему возникает эффект «призрачного кода», как устроена система кэширования в платформе «1С:Предприятие 8.3» и какими способами можно централизованно решить проблему для всех пользователей системы одновременно.
Проанализируем ситуацию, когда даже закомментированный код продолжает работать. Это происходит не из-за программной ошибки в вашем коде, а из-за особенностей работы платформы. Для ускорения запуска и работы клиентского приложения 1С кэширует (сохраняет локально) фрагменты конфигурации. В кэш попадают:
Когда вы вносите изменения в конфигураторе и нажимаете Обновить конфигурацию базы данных, изменения записываются в саму базу. Однако у пользователя, работающего через RDP, в его персональном профиле Windows (папка AppData) уже лежит «слепок» старой версии конфигурации. Если механизм проверки версии кэша дает сбой (что часто бывает при динамическом обновлении), клиентское приложение продолжает обращаться к старому скомпилированному образу модуля. Именно поэтому удаленный или закомментированный код продолжает исполняться — 1С просто не «видит» обновленный текст модуля.
Рассмотрим самый простой способ, который часто применяют администраторы. Если в окне запуска 1С удалить базу из списка и добавить её заново (с тем же путем), проблема исчезает.
Выясним, почему это помогает: при создании новой записи в списке баз 1С генерирует для неё новый уникальный идентификатор (GUID). Кэш привязывается именно к этому идентификатору. Поскольку для системы это «новая» база, она создает для неё пустую папку кэша и загружает актуальные метаданные из базы данных.
Важный нюанс: как правильно отметили участники обсуждения, старый кэш при этом не удаляется физически. Он остается лежать мертвым грузом в папке пользователя, занимая дисковое пространство. Если пользователей много, это может привести к нехватке места на системном диске сервера.
Подключаться к каждому пользователю под RDP вручную — задача неэффективная. Разберем, как автоматизировать этот процесс. Кэш 1С хранится в двух основных директориях профиля пользователя:
%AppData%\1C\1cv8 (Roaming)%LocalAppData%\1C\1cv8 (Local)Для централизованной очистки мы можем создать командный файл (.bat), который будет удалять только папки с кэшем, не затрагивая настройки списка баз (файл ibases.v8i). Рассмотрим пример такого скрипта:
@echo off
set "baseDir1=%AppData%\1C\1cv8"
set "baseDir2=%LocalAppData%\1C\1cv8"
for /d %%i in ("%baseDir1%\????????-????-????-????-????????????") do rd /s /q "%%i"
for /d %%i in ("%baseDir2%\????????-????-????-????-????????????") do rd /s /q "%%i"
echo Кэш успешно очищен!
pause
Этот скрипт находит папки, имена которых соответствуют шаблону GUID (длинные наборы символов), и удаляет их. Использование такого скрипта в качестве Logon Script (сценария входа) в групповых политиках Windows позволит автоматически очищать временные файлы при каждом входе пользователя на сервер.
Рассмотрим еще один штатный способ борьбы с «залипанием» данных. В настройках каждой информационной базы в окне запуска есть поле «Дополнительные параметры запуска». Если прописать туда команду /ClearCache, платформа будет автоматически очищать часть кэша при каждом запуске.
Проанализируем эффективность: данный метод помогает не всегда. Он очищает кэш запросов и кэш тонкого клиента, но иногда игнорирует глубокие структуры метаданных обычных форм. Кроме того, этот параметр замедляет запуск программы, так как системе приходится каждый раз заново скачивать данные с сервера. Мы рекомендуем использовать его только как временную меру.
Выясним главную причину, по которой кэш «сходит с ума». Это динамическое обновление — когда вы сохраняете изменения, пока пользователи работают в базе (нажимая «Да» на вопрос о продолжении при наличии активных сеансов).
В файловом варианте работы на терминальном сервере динамическое обновление — это главный риск. Механизм подмены версий может отработать некорректно для части сеансов.
Рекомендация по правильному обновлению:
taskkill для завершения зависших процессов 1cv8.exe).F7).Если даже полная очистка папок в AppData не помогла, проанализируем редкие случаи:
Local и Roaming.%AppData%\1C\1cv8\ExtCompDir.Подводя итог, можно сказать: проблема «невидимых изменений» — это классика администрирования 1С. Самым надежным решением остается полная очистка временных папок профиля пользователя при закрытых сеансах 1С. Реализовав автоматический скрипт очистки, вы навсегда избавите себя от необходимости объяснять пользователям, почему «программист все сделал, а ничего не работает».