Представьте ситуацию: системный администратор проводил технические работы на сервере и случайно перевел системное время вперед (например, на 15 дней). Спустя некоторое время ошибку обнаружили и вернули время назад. Однако за этот короткий промежуток планировщик 1С успел зафиксировать, что все регламентные задания «успешно выполнились» в будущем. Теперь в поле даты последнего запуска у них красуется дата, которая наступит только через две недели. Соответственно, планировщик считает, что запускать задания не нужно, и информационная база фактически остается без автоматической обработки данных.
В этой статье мы подробно разберем, почему возникает эта проблема, почему ее невозможно решить стандартными программными методами внутри самой 1С, и проанализируем четыре практических способа исправления ситуации в зависимости от архитектуры вашей базы данных (клиент-серверная или файловая).
Первое решение, которое приходит в голову программисту 1С, — написать внешнюю обработку, которая обойдет все регламентные задания в базе и программно изменит дату их последнего выполнения на текущую. Однако при попытке реализовать этот алгоритм мы сталкиваемся с жестким ограничением платформы 1С:Предприятие.
Дату и время последнего выполнения платформа хранит в свойствах объекта регламентного задания: ПоследнееЗадание.Начало или ПоследнееЗадание.Конец. Но дело в том, что во встроенном языке 1С доступ к этим свойствам реализован исключительно для чтения. Записать туда произвольное значение или очистить его программно невозможно. Платформа самостоятельно контролирует эти поля, обновляя их только по факту реального завершения фонового процесса. Именно поэтому стандартные попытки отключить и включить использование задания через код или форму («Выкл» -> «Записать» -> «Вкл» -> «Записать») часто не приносят результата — платформа продолжает считывать старую «будущую» дату запуска из внутренних кэшей или таблиц.
Если ваша база работает в клиент-серверном варианте под управлением СУБД (например, MS SQL Server, PostgreSQL), этот способ является наиболее быстрым и эффективным, особенно когда сбилось расписание у десятков предопределенных регламентных заданий.
Информация о расписании, настройках и истории запусков регламентных заданий хранится на уровне СУБД в системной таблице платформы с именем _ScheduledJobs. Данные в этой таблице находятся в бинарном (сериализованном) виде, поэтому просто точечно поменять дату в одной колонке через стандартный SQL-запрос UPDATE не получится. Однако мы можем полностью очистить эту таблицу или удалить из нее конкретные строки.
Проанализируем пошаговый алгоритм решения проблемы через СУБД:
rmngr) кэширует состояния планировщика регламентных заданий в оперативной памяти. Если вы измените данные в SQL-таблице при работающей службе, менеджер кластера при первом же удобном случае перезапишет ваши изменения в базе данных обратно «будущей» датой из своего кэша.
-- Очистка таблицы регламентных заданий в MS SQL
TRUNCATE TABLE _ScheduledJobs;
ragent считает чистую таблицу _ScheduledJobs, увидит, что истории запусков у предопределенных заданий нет, и начнет их выполнение строго по установленному расписанию, ориентируясь на текущее серверное время.Если «зависло» расписание у дополнительных (внешних) отчетов или обработок, подключенных через Библиотеку стандартных подсистем (БСП), вам не потребуется лезть в базу данных на уровне СУБД. В механизмах БСП заложена архитектура, которая позволяет пересоздавать фоновые задания принудительно через пользовательский интерфейс.
Рассмотрим порядок действий для сброса даты запуска:
Такой цикл действий заставляет БСП удалить старый экземпляр регламентного задания и создать абсолютно новый элемент с пустой историей. Запуск произойдет сразу же при наступлении ближайшего события по расписанию.
В конфигурациях 1С регламентные задания делятся на предопределенные (созданные разработчиком в конфигураторе) и непредопределенные (созданные пользователями или программно в режиме «1С:Предприятие»).
Если зависшие задания не являются предопределенными, самым безопасным и простым методом исправления ситуации будет их ручное пересоздание:
Так как у нового задания история выполнения отсутствует, планировщик начнет его выполнение без оглядки на прошлые сбои времени.
В файловом варианте работы базы данных (когда вся база хранится в одном файле 1Cv8.1CD) напрямую выполнить SQL-запросы к таблице _ScheduledJobs штатными средствами СУБД невозможно. В этом случае у администратора есть два пути решения проблемы.
Вы можете воспользоваться специализированными низкоуровневыми утилитами (например, популярной программой Tool1CD), которые умеют открывать структуру файлов .1CD без запуска платформы 1С. С помощью таких инструментов можно напрямую открыть таблицу _ScheduledJobs внутри файловой базы и вручную очистить ее записи.
Важно: Любое прямое редактирование файлов базы данных сторонними утилитами несет в себе риски необратимого повреждения данных. Перед выполнением этой операции в обязательном порядке сделайте резервную копию файла базы данных (1Cv8.1CD).
Если вы хотите решить проблему исключительно штатными средствами конфигуратора и избежать рисков низкоуровневого редактирования таблиц, выполните следующие действия:
Общие -> РегламентныеЗадания.F7). При этом платформа удалит предопределенные элементы из системных таблиц планировщика.F7).Этот обходной путь заставляет платформу полностью переинициализировать структуру предопределенных регламентных заданий в базе данных, сбросив тем самым всю историю их предыдущих запусков.