В практике администрирования и разработки на платформе «1С:Предприятие 8» часто возникает крайне загадочная на первый взгляд ситуация. Специалист вносит изменения в конфигурацию: добавляет новый реквизит, создает новый регистр накопления или корректирует программный код проведения документов. После обновления под учетной записью администратора все новые механизмы работают безупречно. Однако когда в систему заходят обычные пользователи (особенно работающие через терминальный сервер RDP или программы удаленного доступа), они сталкиваются со странными ошибками: Поле объекта не обнаружено, Движение с таким регистратором невозможно или просто не видят внесенных изменений.
В рамках этой статьи мы подробно проанализируем, почему возникает эта проблема, разберем физические процессы, происходящие в этот момент в системе, и рассмотрим несколько эффективных способов очистки кэша — от простых пользовательских действий до автоматизированных скриптов для системных администраторов.
Описанная ситуация — классический пример сбоя системы после так называемого динамического обновления (которое в профессиональной среде разработчиков часто называют «демоническим»).
Когда разработчик вносит изменения в конфигурацию, платформа позволяет обновить информационную базу без отключения активных пользователей. Это очень удобно для непрерывных производств или крупных офисов, но таит в себе скрытую угрозу. В момент динамического обновления физическая структура таблиц в базе данных SQL или файловой базе меняется, но у пользователей, которые уже были авторизованы в системе, конфигурация продолжает работать на основе старого локального кэша метаданных.
В результате возникает конфликт:
Единственный надежный способ вернуть систему в работоспособное состояние для всех пользователей — это полная очистка кэша метаданных. Рассмотрим, как это сделать правильно.
Это самый простой и доступный способ, который под силу выполнить любому пользователю. При удалении информационной базы из списка запуска и ее повторном добавлении платформа 1С генерирует для нее новый уникальный идентификатор (GUID). В результате папка со старым забагованным кэшем просто перестает использоваться, а для базы создается абсолютно чистый кэш-каталог.
Рассмотрим этот процесс по шагам:
Важный минус метода: у пользователя могут сброситься индивидуальные настройки интерфейса, история выбора значений в полях ввода и размеры некоторых диалоговых окон.
Если мы хотим очистить кэш более элегантно и без удаления базы из списка, можно воспользоваться встроенным ключом запуска платформы. Параметр /ClearCache указывает системе очистить кэш метаданных (но не удаляет пользовательские настройки окон).
Разберем, как его настроить:
/ClearCache (обязательно с косой чертой).После успешного запуска и проведения документов данный параметр рекомендуется убрать из настроек, так как постоянное использование ключа /ClearCache может незначительно замедлить время запуска программы из-за регулярного перестроения таблиц локального кэша.
Если нам необходимо точечно очистить кэш вручную, не затрагивая конфигурационный файл списка баз ibases.v8i, мы можем удалить папки временных файлов напрямую через проводник Windows.
Локальный кэш каждого пользователя хранится в двух скрытых системных директориях:
C:\Users\<Имя_Пользователя>\AppData\Local\1C\1Cv8C:\Users\<Имя_Пользователя>\AppData\Roaming\1C\1Cv8Внутри этих директорий располагаются папки с длинными именами из букв и цифр (например, 8a7e584f-e1c9-4672-87ad-d34e6f47702a). Внутри них находятся рабочие кэш-файлы конфигурации, такие как Config, ConfigSave, DBNameCache и SICache.
Для очистки кэша выполните следующие действия:
ibases.v8i (хранящий список баз) удалять не нужно.В условиях работы через терминальный сервер (RDP) ручная очистка кэша у каждого пользователя превращается в трудоемкую рутину. Для решения этой задачи системные администраторы используют специальные скрипты автоматизации.
Проанализируем пример пакетного файла .bat, который можно прописать в автозагрузку терминального сервера или запускать по расписанию в ночное время. Этот скрипт завершает зависшие процессы 1С и очищает кэш всех пользователей сервера, сохраняя при этом файлы со списками баз:
@echo off
taskkill /f /im 1cv8.exe
taskkill /f /im 1cv8c.exe
echo Очистка временных файлов 1С у всех пользователей...
for /d %%i in ("C:\Users\*") do (
if exist "%%i\AppData\Local\1C\1Cv8" (
for /d %%j in ("%%i\AppData\Local\1C\1Cv8\*") do (
rd /s /q "%%j"
)
)
if exist "%%i\AppData\Roaming\1C\1Cv8" (
for /d %%j in ("%%i\AppData\Roaming\1C\1Cv8\*") do (
if not "%%~nxj"=="ibases.v8i" (
rd /s /q "%%j"
)
)
)
)
echo Очистка кэша успешно выполнена!
pause
Бывают редкие случаи, когда очистка локального кэша на рабочих станциях пользователей не помогает исправить ошибку. Это означает, что поврежденный или устаревший кэш метаданных завис на стороне самого сервера приложений «1С:Предприятие».
Для его принудительного сброса выполните следующие шаги:
1C:Enterprise 8.3 Server Agent и нажмите «Остановить»).C:\Program Files\1cv8\srvinfo.reg_1541). Внутри него будут находиться папки баз данных с их внутренними идентификаторами.1CV8Reg.lst).Чтобы избежать подобных аварийных ситуаций и минимизировать простои пользователей, рекомендуем придерживаться простых правил администрирования: