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

← На главную

При работе с файловыми базами 1С:Предприятие 8.3 программисты часто сталкиваются с необъяснимым поведением: один и тот же код, запущенный вручную через внешнюю обработку, и тот же код, выполняемый регламентным заданием, выдает разные результаты. Ситуация осложняется тем, что даже после изменения программного кода (например, удаления ограничения ВЫБРАТЬ ПЕРВЫЕ 10), фоновое задание продолжает работать по старому алгоритму. Проанализируем, почему так происходит, и как правильно «сбросить» состояние системы.

Причина 1: Специфика кэширования модулей в файловом режиме

В файловом варианте работы регламентные задания выполняются в контексте специального фонового процесса. Несмотря на то, что задание запускается от имени конкретного пользователя, платформа создает для него отдельную среду выполнения. Основная проблема кроется в том, что 1С кэширует скомпилированные модули не только в папке пользователя Roaming, но и в локальном хранилище Local.

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

Очистка папки Local: Перейдем в каталог %LOCALAPPDATA%\1C\1cv8\. Найдем папку с уникальным идентификатором вашей базы и полностью удалим в ней содержимое папки Config. Именно здесь часто «залипает» старый код фоновых заданий.
Очистка папки Roaming: Стандартная процедура очистки %APPDATA%\1C\1cv8\ также необходима, но для фоновых заданий она менее критична, чем локальная.
Удаление базы из списка: Рассмотрим радикальный, но эффективный способ — удаление информационной базы из списка в окне запуска 1С и ее повторное добавление. Это принудительно создаст новые папки кэша с новыми ID.

Причина 2: «Призрачные» сеансы фоновых заданий

Выясним причину, по которой обычная чистка папок иногда не помогает. В 1С 8.3 планировщик заданий для файловых баз может удерживать процесс 1cv8.exe активным в памяти даже после завершения видимой работы. Рассмотрим алгоритм действий:

Перед очисткой кэша необходимо убедиться, что все процессы 1С завершены. Откроем диспетчер задач и проверим наличие процессов 1cv8.exe, 1cv8c.exe или 1cv8s.exe. Если регламентное задание «зависло» или планировщик держит сессию открытой, файлы кэша будут заблокированы, и их удаление не принесет результата, так как рабочие данные останутся в оперативной памяти процесса.

Причина 3: Особенности работы запросов в фоновых заданиях

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


Функция ПолучитьОстаткиПоСхемеНастроек(схеманастройки, СоСкладами)
    Запрос = новый Запрос();
    Запрос.УстановитьПараметр("СписокСкладов", схеманастройки.Склады.выгрузитьколонку("Склад"));
    Запрос.УстановитьПараметр("СписокНоменклатуры", схеманастройки.Номенклатура.выгрузитьколонку("Номенклатура"));
    
    Запрос.Текст = "ВЫБРАТЬ 
                   |    ТоварыНаСкладахОстатки.Номенклатура,";
    Если СоСкладами тогда
        Запрос.Текст = Запрос.Текст + "    ТоварыНаСкладахОстатки.Склад,";
    КонецЕсли;
    
    Запрос.Текст = Запрос.Текст + "    ТоварыНаСкладахОстатки.КоличествоОстаток КАК Остаток,
                   |ИЗ
                   |    РегистрНакопления.ОстаткиТоваров.Остатки КАК ТоварыНаСкладахОстатки
                   |ГДЕ
                   |    ТоварыНаСкладахОстатки.КоличествоОстаток > 0";
    // ... дальнейшая достройка текста запроса
КонецФункции

Обратим внимание на критический момент: в запросе к виртуальной таблице РегистрНакопления.ОстаткиТоваров.Остатки не указан параметр Период. Посмотрим на последствия:

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

Рекомендация: Всегда передавайте в виртуальные таблицы явный параметр даты, например ТекущаяДата(), чтобы гарантировать идентичность выборок.

Причина 4: Инициализация параметров сеанса и RLS

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

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

Итоговый чек-лист для исправления проблемы

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

Завершим все процессы: Закроем 1С и «убьем» процессы через диспетчер задач.
Очистим кэш полностью: Удалим содержимое папок в %LOCALAPPDATA%\1C\1cv8\ и %APPDATA%\1C\1cv8\.
Добавим Период в запросы: Перепишем запросы к виртуальным таблицам с использованием явной даты.
Проверим RLS: Убедимся, что все параметры сеанса, необходимые для работы запроса, инициализируются в модуле сеанса, а не в модуле управляемого приложения или формах.
Пересчитаем итоги: В файловых базах полезно периодически запускать Тестирование и исправление с флагом «Пересчет итогов», чтобы исключить ошибки в самих таблицах остатков.

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