Сбросили кэш хранилища в 1С: три способа и что делать после

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

Чистить имеет смысл в четырёх случаях: хранилище «тормозит» при получении версий, после обновления платформы вылезают ошибки чтения, объекты в списке показываются в устаревшем состоянии, на диске пользователя раздулась папка с локальными данными 1С. Если же хранилище недоступно по сети или падает по правам, кэш ни при чём, и чистка только отнимет время.

Что лежит в кэше хранилища и когда его трогать

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

Кэшей два, и путать их не стоит:

• 🧩 Локальный кэш — относится к конкретному пользователю и его подключению к хранилищу. Чистится безопасно, при следующем обращении Конфигуратор соберёт его заново.
• 🗄 Глобальный кэш версий — общий для всех подключений на этом компьютере. Его очистка заметнее по времени: версии придётся подтягивать заново.

Сами данные хранилища (история версий, пользователи, захваты) лежат в файле или базе хранилища и при очистке кэша не теряются. Очищаем только копию на клиенте.

Признаки, что кэш пора сбросить:

1. Конфигуратор долго «думает» при открытии окна версий хранилища.
2. Список объектов показывает старую версию, хотя коллега уже поместил новую.
3. Получение конфигурации завершается ошибкой чтения, которой раньше не было.
4. После переустановки или смены версии платформы хранилище ведёт себя странно.
5. Размер папки данных 1С в профиле перевалил за несколько гигабайт.

Подготовка: что проверить до очистки

Две минуты на подготовку сэкономят час на восстановление.

Закройте все копии Конфигуратора и клиентов 1С, подключённых к хранилищу. Если на машине несколько пользователей Windows, чистка касается только текущего профиля.

Убедитесь, что у вас есть доступ к хранилищу: адрес (путь к файлу или адрес сервера), пользователь и пароль. Они понадобятся, потому что после очистки Конфигуратор запросит подключение заново.

Запишите версию платформы. Если планируете обращаться в поддержку, это первое, о чём спросят.

Способ 1. Очистка запуском Конфигуратора с ключом

Самый чистый вариант: Конфигуратор сам знает, где лежит его кэш, и сам удаляет нужное. Запуск идёт в пакетном режиме, окно не открывается.

Параметры командной строки, которые отвечают за кэш хранилища:

Пример для файловой базы (путь, пользователь и пароль подставьте свои):

"C:\Program Files\1cv8\<номер версии>\bin\1cv8.exe" DESIGNER /F "D:\Bases\Dev" /N "Разработчик" /P "пароль" /ConfigurationRepositoryF "\\server\repo\main" /ConfigurationRepositoryN "Разработчик" /ConfigurationRepositoryP "пароль" /ConfigurationRepositoryClearCache /Out "D:\Temp\clear.log"

Для серверной базы вместо /F "путь" используется /S "сервер\имя_базы". Параметры хранилища /ConfigurationRepositoryF, /ConfigurationRepositoryN и /ConfigurationRepositoryP задают адрес, имя и пароль пользователя хранилища.

Разберём, что тут важно:

• 📝 Обязательно добавляйте /Out с путём к файлу журнала. Без него вы не узнаете, прошла ли очистка.
• 🔑 Кавычки нужны, если в путях или паролях есть пробелы и спецсимволы.
• 🧭 Номер версии в пути к 1cv8.exe должен совпадать с той платформой, которой вы работаете. Запуск «чужой» версией создаст свой кэш рядом.

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

Способ 2. Ручное удаление файлов кэша

Нужен, когда Конфигуратор не стартует, ключ не сработал или вы хотите сбросить абсолютно всё сразу.

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

%LOCALAPPDATA%\1C\1cv8
%APPDATA%\1C\1cv8

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

Порядок такой:

1. Закройте все окна 1С и убедитесь в диспетчере задач, что процессов 1cv8.exe и 1cv8c.exe не осталось.
2. Не удаляйте каталог целиком. Переименуйте подпапки с кэшем (например, добавьте _old в конец имени) или переместите их на другой диск.
3. Запустите Конфигуратор и подключитесь к хранилищу. Платформа пересоздаст нужные файлы.
4. Убедитесь, что всё работает, и только потом удаляйте переименованное.

Такая схема страхует от ошибки: если вы случайно задели не то, достаточно вернуть имена обратно.

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

Способ 3. Через сам Конфигуратор

Если Конфигуратор открывается, то можно обойтись без командной строки и проводника. Откройте конфигурацию, подключённую к хранилищу, и найдите пункты работы с хранилищем в меню «Конфигурация». Там есть управление подключением: можно отключиться от хранилища и подключиться заново.

Отключение и повторное подключение — полумера, но часто она достаточна:

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

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

Файловое и серверное хранилище: в чём разница при чистке

Кэш в обоих случаях лежит у клиента, но проблемы возникают в разных местах.

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

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

Быстрый способ понять, где корень проблемы:

Что делать после очистки

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

Проверьте по списку:

• ✅ Подключение к хранилищу восстановлено, пользователь определён правильно.
• ✅ Список версий совпадает с тем, что видят коллеги.
• ✅ Захваты объектов отображаются корректно.
• ✅ Получение конфигурации из хранилища проходит без ошибок.

Если после чистки ошибка осталась, сначала проверьте простое: тот ли пользователь, не истёк ли пароль, одна ли версия платформы у всех разработчиков. Затем посмотрите журнал, который вы записывали в /Out.

Пара ситуаций, когда сброс кэша не нужен вообще:

• Хранилище не открывается с самого начала. Значит, неверный адрес или нет прав. Кэш ещё не создан.
• Ошибка «объект захвачен другим пользователем». Это штатная блокировка, а не проблема кэша. Её снимает владелец захвата или администратор хранилища.
• Тормозит обычная работа в базе, а не хранилище. Тут нужны другие меры: сжатие таблиц, чистка кэша клиента и сервера, проверка индексов.

Мини-кейс из практики. У разработчика список версий хранилища открывался по семь-восемь минут, у остальных пяти человек за полминуты. Сеть и сервер проверили, всё в порядке. Очистили глобальный кэш версий только на его машине, и окно стало открываться за обычное время. Вывод простой: если тормозит один, начинайте с его компьютера, а не с сервера.

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

Как не доводить до чистки: профилактика

Кэш хранилища ломается не сам по себе. Обычно за сбоем стоит одна из причин из списка.

Хорошая привычка: раз в квартал выполнять профилактическую очистку на тех машинах, где активно работают с хранилищем. Для этого достаточно положить команду из способа 1 в .bat-файл и запускать вручную. Пароли в такой файл лучше не вписывать: храните их отдельно или запрашивайте при запуске.

Для командной работы пригодится короткий регламент. Его можно оформить чек-листом и повесить на общую страницу:

Частые вопросы