В практике разработки и администрирования 1С нередко возникает ситуация, когда внешний отчет или обработка долгое время функционирует штатно, но в определенный момент на одном из клиентских компьютеров начинает возвращать неверные данные или выполняться по непредвиденному сценарию. При этом ручная очистка пользовательского кэша временно решает проблему, но через некоторое время сбой повторяется на другом рабочем месте. Разберем основные причины такого поведения и способы окончательного устранения неполадки.
Анализ причин нестабильной работы обработки
Плавающие ошибки, которые «лечатся» очисткой временных файлов, чаще всего вызваны следующими факторами:
Динамическое обновление конфигурации («демоническое обновление»). При частом применении изменений без перезапуска сеансов пользователей и службы сервера 1С локальный кэш метаданных на клиентских машинах рассинхронизируется. В результате платформа может исполнять устаревшие или частично поврежденные скомпилированные модули.
Конфликт сохраненных пользовательских настроек. Если в обработке изменялся состав реквизитов, структура форм или схема компоновки данных, старые сохраненные настройки формы конкретного пользователя могут подставлять невидимые отборы или неинициализированные значения.
Недетерминированность запросов. Отсутствие явного оператора УПОРЯДОЧИТЬ ПО в текстах запросов приводит к тому, что СУБД возвращает строки в произвольном порядке, меняя логику последующей обработки выборок.
Блокировка временных файлов антивирусом. Фоновое сканирование папок кэша 1С антивирусным ПО может приводить к сбоям записи бинарных структур.
Решение 1. Отказ от динамических обновлений и корректная очистка кэша
Проанализируем шаги по стабилизации работы платформы и устранению повреждений кэша:
Исключите обновление конфигурации в динамическом режиме. Любые обновления конфигурации БД следует выполнять исключительно в монопольном режиме с завершением всех пользовательских сеансов и плановым перезапуском процессов сервера 1С.
Использование параметра запуска для автоматической очистки кэша. Для проблемных рабочих мест укажем в дополнительных параметрах запуска информационной базы ключ:/ClearCache
Данный параметр форсирует обновление кэша метаданных при каждом запуске сеанса.
Перерегистрация базы в списке запуска. Удалим информационную базу из списка в окне запуска и добавим ее заново. При этом создается новый идентификатор базы (GUID), что исключает подтягивание старых поврежденных каталогов из AppData\Local\1C и AppData\Roaming\1C.
Решение 2. Внедрение журнала логирования и отладка кода
Когда алгоритм дает сбой непредсказуемо, необходимо обеспечить прозрачность его выполнения. Добавим запись ключевых параметров и этапов выполнения в журнал регистрации или отдельный текстовый лог-файл:
// Пример записи отладочной информации в Журнал регистрации
ЗаписьЖурналаРегистрации(
"ВыполнениеОбработки.Диагностика",
УровеньЖурналаРегистрации.Информация,
Метаданные.Обработки.НазваниеОбработки,
,
"Параметры запуска: Организация = " + Строка(Организация) + "; Период = " + Строка(Период)
);
Такой подход позволит при очередном инциденте точно зафиксировать, какие входные данные и параметры были переданы в алгоритм на конкретном рабочем месте, исключив фактор субъективной оценки пользователя.
Решение 3. Регламентные процедуры и проверка целостности
Для предотвращения логических сбоев выполним комплекс профилактических мер:
Тестирование и исправление информационной базы. В режиме Конфигуратора выполним реиндексацию таблиц информационной базы, проверку логической целостности и пересчет итогов. Для файловых баз запустим утилиту chdbfl.exe.
Настройка исключений безопасности. Добавим каталоги временных файлов пользователя %TEMP%, каталоги данных 1С (AppData\Local\1C, AppData\Roaming\1C) и файлы баз данных в список исключений антивирусного сканера.
Явная инициализация переменных. В модуле объекта и модуле формы обработки проверим, чтобы все таблицы значений, структуры параметров и списки инициализировались явным образом перед началом основного расчета, не полагаясь на остаточные значения в памяти формы.