Почему возникает ошибка «The query processor could not produce a query plan» при формировании книги покупок в 1С?

При работе с конфигурациями 1С, такими как Комплексная автоматизация или УПП, пользователи периодически сталкиваются с критической ошибкой SQL Server при формировании регламентированных отчетов. Текст ошибки указывает на то, что процессору запросов не удалось построить план выполнения из-за того, что рабочая таблица (worktable) превышает лимит в 8060 байт на строку. Разберем, почему это происходит и как это исправить.

Суть проблемы

Данная ошибка возникает, когда 1С генерирует сложный запрос с большим количеством полей, участвующих в группировке (GROUP BY). Если в запросе используются обращения к реквизитам через «точку» (например, Документ.Реквизит.Номер), SQL Server вынужден включать в промежуточную (рабочую) таблицу не только ссылку, но и строковые данные большого объема. Если сумма длин этих данных превышает 8060 байт, SQL Server останавливает выполнение запроса, так как не может обработать такую «широкую» запись.

Способ 1: Изменение уровня совместимости базы данных

Самым быстрым, но не всегда рекомендуемым способом является изменение уровня совместимости базы данных в SQL Server. Более новые версии оптимизатора запросов (в SQL 2012+) могут иначе распределять нагрузку, что позволяет избежать этой ошибки без правки кода.

Для реализации этого решения:

1. Откройте SQL Server Management Studio.
2. Выберите нужную базу данных.
3. Нажмите правой кнопкой мыши -> Свойства (Properties).
4. Перейдите в раздел Параметры (Options).
5. В поле Уровень совместимости (Compatibility level) установите значение, соответствующее SQL Server 2008 (100) или актуальное для вашей версии.

Важно: Этот метод может привести к изменению планов выполнения других запросов, что иногда негативно сказывается на общей производительности базы данных.

Способ 2: Оптимизация запроса в коде 1С

Более надежным методом является переписывание проблемного запроса. Суть доработки заключается в том, чтобы исключить обращение к реквизитам через точку в секциях ВЫБРАТЬ и СГРУППИРОВАТЬ ПО, если эти поля содержат длинные строки.

Рассмотрим пример оптимизации модуля КнигаПокупок1137. Вместо обращения к реквизитам через сложные пути, нам следует вычислять значения заранее и использовать их в качестве коротких идентификаторов или заранее подготовленных данных.

Шаг 1: Изменение логики получения данных

Найдите в модуле менеджера функцию формирования текста запроса. Если вы видите конструкцию, которая обращается к реквизиту объекта напрямую в группировке, замените её на результат вычисления ВЫБОР КОГДА.

Пример оптимизированного блока кода для запроса:

| ВЫБОР
|    КОГДА НЕ НДСЗаписиКнигиПокупок.ИсправленныйСчетФактура В (&ПустыеДокументыИсправления)
|        ТОГДА НДСЗаписиКнигиПокупок.ИсправленныйСчетФактура.Номер
|    КОГДА НДСЗаписиКнигиПокупок.ВидЦенности В (&ВидыЦенностей_НалоговыйАгент)
|        ТОГДА НДСЗаписиКнигиПокупок.ДокументОплаты.Номер
|    ИНАЧЕ НДСЗаписиКнигиПокупок.СчетФактура.Номер
| КОНЕЦ КАК ДокументОснованиеСчетаФактурыНомер

Шаг 2: Корректировка секции группировки

После того как мы дали псевдоним (например, ДокументОснованиеСчетаФактурыНомер), необходимо использовать именно этот псевдоним в секции СГРУППИРОВАТЬ ПО вместо исходного длинного выражения. Это критически важно, так как именно на этапе группировки SQL Server пытается сформировать «тяжелую» рабочую строку.

Таким образом, мы разгружаем процессор запросов, передавая ему более компактные данные, что позволяет уложиться в лимит 8060 байт и успешно сформировать Книгу покупок без ошибок.

Рекомендации

Мы настоятельно советуем сначала проанализировать запрос с помощью консоли запросов и выяснить, какие именно поля при группировке создают избыточный вес строки. Оптимизация кода 1С — это правильный путь, который обеспечит стабильность системы даже при переходе на новые версии SQL Server, не затрагивая при этом общие настройки производительности сервера.