В практике разработчика 1С иногда возникают ситуации, которые кажутся мистическими: программный код ведет себя безупречно, пока мы идем по нему «шагами» в отладчике, но стоит запустить систему в обычном режиме, как логика ломается. Особенно часто это проявляется в крупных конфигурациях, таких как УПП (Управление производственным предприятием), на стыке механизмов проведения документов и контроля остатков. Разберем детально, почему так происходит и как с этим бороться.
Рассмотрим ситуацию, описанную в теме. Документ в процессе проведения записывает свои движения в базу данных, после чего вызывается функция для проверки отрицательных остатков. В режиме отладки (с точкой останова) проверка находит «минусы» и блокирует проведение. Без отладчика документ проводится, игнорируя нехватку товара. Это классический пример проблемы транзакционного кэширования.
Проанализируем механику взаимодействия платформы 1С и СУБД. Когда мы вызываем метод Движения.Записать() внутри транзакции проведения, данные не всегда моментально попадают в физические таблицы базы данных, доступные для стандартных SQL-запросов других сеансов или даже вложенных вызовов. Они могут находиться во внутреннем буфере платформы. Точка останова в конфигураторе создает паузу в выполнении серверного потока. Эта пауза часто провоцирует принудительный сброс (flush) накопленных изменений из памяти сервера приложений в СУБД. В обычном же режиме код выполняется настолько быстро, что запрос в функции контроля остатков обращается к данным, которые еще «не долетели» до таблиц итогов или регистров накопления.
Выясним причину, по которой обычное использование метода Сообщить() может вводить в заблуждение при диагностике таких проблем. Если функция контроля остатков выполняется на сервере (что типично для УПП), метод Сообщить() передает данные в очередь сообщений, которая будет показана пользователю только после завершения серверного вызова. Если же произошел «тихий» программный сбой или логический выход из функции, мы можем просто не увидеть сообщение.
Для надежной диагностики вместо Сообщить() мы будем использовать ЗаписьЖурналаРегистрации. Это позволит нам точно убедиться, заходит ли система в функцию контроля и какие данные передаются в параметрах.
// Вставим в начало функции контроля остатков
ЗаписьЖурналаРегистрации("КонтрольОстатков.Диагностика",
УровеньЖурналаРегистрации.Информация,
,
,
"Функция вызвана. Количество строк в ТЗ: " + ПараметрТаблицаДвижений.Количество());
Разберем влияние настроек общего модуля. В 1С существует механизм «Повторное использование возвращаемых значений». Если этот флаг установлен («На время вызова» или «На время сеанса»), то при повторном обращении к функции с теми же параметрами 1С не будет выполнять код функции заново, а просто вернет результат из кэша.
Важно помнить, что в режиме отладки этот механизм кэширования платформой часто игнорируется или работает иначе, чтобы разработчик мог видеть актуальное состояние кода. Проверим свойства модуля, где расположена функция проверки:
Не использовать.Посмотрим на пример передачи данных. В УПП часто таблицы движений выгружаются в ТЗ и передаются в функцию. В платформе 8.3.12 (и некоторых соседних релизах) наблюдались ошибки оптимизации при передаче больших объектов между серверными вызовами. Если ТЗ передается в функцию общего модуля, который не является привилегированным, а сам вызов происходит внутри сложной транзакции, данные могут быть интерпретированы некорректно.
Попробуем изменить способ передачи данных, явно указав ключевое слово Знач, чтобы исключить влияние изменения таблицы внутри функции на исходный объект:
Функция ПроверитьОстатки(Знач ТаблицаДанных, СтруктураПараметров) Экспорт
// Код функции
КонецФункции
Проанализируем ситуацию с точки зрения багов платформы. Версия 8.3.12 известна специфической оптимизацией байт-кода. В режиме отладки сервер исполняет код в режиме интерпретации, максимально близком к исходному тексту. В рабочем режиме код компилируется в оптимизированный образ. Иногда «битый» серверный кэш приводит к тому, что исполняется старая версия модуля.
Рекомендуемые шаги по очистке:
sncfg и reg_1541 (локальный кэш конфигурации на сервере).Выясним, как функция работает с запросом. Если внутри функции используется МенеджерВременныхТаблиц, его поведение в отладке и в обычном режиме может отличаться из-за времени жизни контекста. В режиме отладки контекст сеанса удерживается активным, пока открыто окно отладчика. В обычном режиме менеджер может быть уничтожен или очищен сборщиком мусора сразу после выхода из области видимости.
Если ваша функция контроля остатков использует запрос к временным таблицам, сформированным ранее, убедитесь, что менеджер временных таблиц передается в запрос явно и не пересоздается внутри функции:
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = ПереданныйМенеджер;
Запрос.Текст = "ВЫБРАТЬ * ИЗ ВТ_Движения ГДЕ ...";
Для устранения разницы в поведении кода выполним следующие действия:
Движения.Записать(). Это заставит платформу актуализировать данные в транзакции.Предупреждение (на клиенте) или пустой цикл/ожидание на 1 секунду перед проверкой. Если после паузы всё работает — проблема в скорости синхронизации данных между сервером приложений и СУБД.
УстановитьПривилегированныйРежим(Истина);
Результат = ОбщийМодуль.ПроверитьОстатки(ТЗ);
УстановитьПривилегированныйРежим(Ложь);
Следуя этим шагам, мы сможем нивелировать различия между режимом отладки и промышленной эксплуатацией, обеспечив стабильную работу механизмов контроля в 1С:УПП.