При переходе на новые релизы платформы разработчики нередко сталкиваются с неожиданным поведением системы. Одним из таких «сюрпризов» в версии 8.3.22.2239 стала специфическая проблема: отчеты, построенные на системе компоновки данных (СКД), начинают выдавать синтаксическую ошибку при выборе определенных периодов. Рассмотрим подробнее, почему за август отчет может работать идеально, а при выборе октября или ноября — выдавать критический сбой, и выясним, как это исправить.
Типичная картина проблемы выглядит так: отчет не имеет собственной формы, использует стандартные механизмы БСП (Библиотеки стандартных подсистем) и опирается на стандартный период в параметрах. При попытке формирования за определенные месяцы система выдает следующее сообщение:
Ошибка при вызове метода контекста (СкомпоноватьРезультат)
по причине:
Ошибка исполнения отчета
по причине:
Ошибка получения данных
по причине:
Ошибка в выражении
по причине:
Синтаксическая ошибка
Важно обратить внимание, что ошибка возникает именно на этапе СкомпоноватьРезультат. Это сигнализирует о том, что проблема кроется не в коде запроса, написанном программистом, а в том, как процессор компоновки данных интерпретирует настройки и транслирует их в итоговый SQL-запрос к базе данных.
Разберем природу этого «глюка». В линейке 8.3.22 (в частности, в релизе 2239) были внедрены существенные изменения в оптимизатор запросов и механизмы генерации SQL-кода. В некоторых случаях платформа некорректно обрабатывает литералы дат или условия, накладываемые через стандартные периоды.
Проблема часто связана с тем, что при определенных границах периода (например, когда дата начала или окончания попадает на специфическое число) механизм компоновки генерирует некорректную конструкцию в секции ГДЕ или ИМЕЮЩИЕ. Платформа может «забыть» вставить пробел перед ключевым словом SQL или неправильно типизировать параметр даты, что приводит к тому, что СУБД (MS SQL Server или PostgreSQL) возвращает ошибку синтаксиса, которую 1С транслирует пользователю в общем виде.
Поскольку корень проблемы лежит в самой платформе, самым надежным решением будет установка исправленного релиза. Рассмотрим рекомендации специалистов:
Если обновить платформу на сервере прямо сейчас невозможно (например, из-за регламентов компании), проанализируем способ обхода ошибки через изменение схемы компоновки данных. Ошибка часто «цепляется» именно за объект СтандартныйПериод.
Выполним следующие шаги по шагам:
Период), который имеет тип СтандартныйПериод.НачалоПериода и КонецПериода с типом Дата.Такой подход заставляет платформу использовать простую типизацию дат (литералы), что исключает сложные преобразования объекта СтандартныйПериод, на которых и «спотыкается» баг платформы.
Иногда после обновления или при странном поведении отчетов на конкретном релизе помогает полная очистка кэша. Посмотрим, как это сделать правильно:
1C:Enterprise 8.3 Server Agent.C:\Program Files\1cv8\srvinfo).snccntx и временных файлов внутри папок с GUID баз (будьте осторожны, не удалите файлы конфигурации самой базы 1Cv8.1CD, если у вас файловый вариант).Это заставит платформу заново построить планы запросов и скомпоновать схемы, что в некоторых случаях устраняет «фантомные» синтаксические ошибки.
Проанализируем еще несколько моментов, которые помогут локализовать проблему, если вышеописанное не помогло:
Варианты отчетов.Формирование отчета. Там может содержаться более детальный стек вызовов, указывающий на конкретный общий модуль, где происходит сбой.Автозаполнение в запросе СКД и прописать все поля и условия вручную на соответствующих закладках. Иногда ошибка кроется в том, как механизм автозаполнения добавляет условия по датам в секцию ГДЕ.Подводя итог, можно сказать, что ситуация с платформой 8.3.22.2239 — это классический пример того, как исправления в ядре системы могут затронуть прикладные механизмы. Наилучшим выходом остается своевременное обновление на стабильные патчи.