Многие разработчики при работе с расширениями в 1С:Предприятие 8.3 сталкиваются с очень неприятной проблемой. При попытке написать запрос в расширении (например, для динамического списка или модуля объекта), если в условии соединения (левого, правого или полного) участвует поле составного типа, платформа выдает ошибку:
"Неверные параметры в операции сравнения. Нельзя сравнивать поля неограниченной длины..."
При этом конструктор запросов перестает работать, выдавая эту же ошибку при нажатии на кнопку "ОК". Давайте подробно разберем, почему возникает эта проблема, проанализируем её технические корни и рассмотрим эффективные способы её решения.
Проанализируем техническую сторону вопроса. Ошибка возникает из-за специфики трансляции запроса платформой 1С в язык SQL, понятный системе управления базами данных (СУБД). Когда в расширении используется поле составного типа, особенно если не все типы из этого состава добавлены в само расширение (или если используется тип ЛюбаяСсылка), платформа не всегда может корректно определить точную структуру этого поля.
В результате при формировании SQL-запроса 1С интерпретирует такое поле как тип неограниченной длины (например, NVARCHAR(MAX)). Однако реляционные СУБД, такие как MS SQL Server или PostgreSQL, на уровне синтаксиса запрещают выполнять операции сравнения или соединения (JOIN) по полям неограниченной длины. Именно это ограничение базы данных мы и видим в виде текста ошибки платформы.
Стоит отметить, что разработчики 1С признали данную проблему (в баг-трекере фигурируют ошибки с кодами 60007478, 00-00600074, 60009521). И хотя в некоторых релизах (например, 8.3.23.1865) заявлялось об исправлении, зачастую это касалось только простых условий в секции ГДЕ, тогда как в соединениях (JOIN) или динамических списках баг продолжал воспроизводиться.
Посмотрим на практические методы обхода этой ошибки, которые помогут вам продолжить полноценно использовать механизм расширений.
Техническая поддержка 1С подтвердила, что глубокие изменения в механизме трансляции запросов для расширений были внесены в более новых версиях платформы. Если у вас есть возможность обновить систему, выполните следующие действия:
Если обновление платформы временно невозможно, разберем обходной вариант, предложенный службой поддержки 1С. Проблема часто кроется в свойстве ЛюбаяСсылка у составного типа.
В этом случае платформа будет четко "видеть" границы типов, и сообщение об ошибке при конструировании запроса пропадет.
Рассмотрим подход, который отлично помогает прямо в тексте запроса. Чтобы избежать ситуации, когда платформа генерирует поле неограниченной длины, мы можем принудительно указать нужный тип в самом соединении.
Используйте функцию ВЫРАЗИТЬ для приведения поля составного типа к конкретному ссылочному типу. Это подскажет платформе, как именно генерировать SQL-код.
ВЫБРАТЬ
ДокументПродажи.Ссылка КАК Документ,
СправочникКонтрагенты.Наименование КАК Клиент
ИЗ
Документ.РеализацияТоваровУслуг КАК ДокументПродажи
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК СправочникКонтрагенты
// Принудительно типизируем составное поле перед сравнением
ПО (ВЫРАЗИТЬ(ДокументПродажи.КонтрагентСоставной КАК Справочник.Контрагенты)) = СправочникКонтрагенты.Ссылка
Если конструктор запросов упорно отказывается сохранять запрос в динамическом списке или форме расширения, мы можем применить программный метод. Разберем по шагам, как задать текст запроса в модуле формы, минуя проверку метаданных в конфигураторе.
Для этого в расширении формы используем обработчик ПриСозданииНаСервере:
&НаСервере
Процедура Расш1_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Переопределяем текст запроса динамического списка программно
ТекстЗапроса =
"ВЫБРАТЬ
| ТаблицаОсновная.Ссылка КАК Ссылка,
| ТаблицаДоп.Реквизит КАК ДопРеквизит
|ИЗ
| Справочник.Номенклатура КАК ТаблицаОсновная
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДополнительныеДанные КАК ТаблицаДоп
| ПО ТаблицаОсновная.Ссылка = ТаблицаДоп.Объект"; // Объект - составной тип
// Устанавливаем текст запроса напрямую в список
Список.ПроизвольныйЗапрос = Истина;
Список.ТекстЗапроса = ТекстЗапроса;
КонецПроцедуры
В сложных выборках проанализируем вариант с разбиением логики на этапы. Это особенно актуально при работе с модулями объектов или общими модулями. Сначала мы выбираем данные во временную таблицу, строго типизируя нужные поля, а затем выполняем соединение.
// Шаг 1: Помещаем данные с типизацией составного поля
ВЫБРАТЬ
Таблица1.Ссылка КАК Ссылка,
ВЫРАЗИТЬ(Таблица1.ПолеСоставногоТипа КАК Документ.ЗаказКлиента) КАК ПолеЗаказ
ПОМЕСТИТЬ ВТ_ТипизированныеДанные
ИЗ
РегистрСведений.СвязиОбъектов КАК Таблица1;
// Шаг 2: Выполняем простое соединение
ВЫБРАТЬ
ВТ_Данные.Ссылка КАК Ссылка,
Заказы.СуммаДокумента КАК Сумма
ИЗ
ВТ_ТипизированныеДанные КАК ВТ_Данные
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ЗаказКлиента КАК Заказы
ПО ВТ_Данные.ПолеЗаказ = Заказы.Ссылка
Еще один важный нюанс, на который стоит обратить внимание: убедитесь, что свойство РежимСовместимости в вашем расширении строго соответствует режиму совместимости основной конфигурации базы данных. Если режим совместимости расширения установлен в значение "Не использовать", а основная конфигурация работает, например, в режиме 8.3.21, это может вызывать конфликты в трансляции типов. Приведите их к единому значению.
Если вы постоянно используете расширения и не хотите каждый раз переносить десятки объектов метаданных (справочники, документы, регистры) просто ради того, чтобы конструктор запросов "увидел" все составляющие типы и позволил собрать запрос визуально, воспользуйтесь хитростью от опытных разработчиков.
Пишите и отлаживайте сложные запросы с составными типами в обычной обработке в копии основной базы (или в консоли запросов). Когда запрос полностью готов и проверен, просто скопируйте его текст и вставьте в модуль расширения. Это избавит вас от необходимости перегружать расширение лишними заимствованными метаданными и ускорит процесс разработки.