При разработке отчетов и обработок в системе 1С:Предприятие программисты часто сталкиваются с необходимостью наложить фильтр по текстовому представлению объекта в запросе. Типичный сценарий: у нас есть текстовая строка (например, инвентарный номер, артикул или наименование товара), полученная из внешнего источника или таблицы значений, и нам нужно найти соответствующий элемент в базе данных с помощью запроса.
Однако при попытке написать тривиальное условие вида ИнвентарныеНомераОС.Представление = &ИнвентНомер платформа возвращает крайне неприятную ошибку: «Неверные параметры в операции сравнения. Нельзя сравнивать поля неограниченной длины и поля несовместимых типов». Попытки обойти это ограничение с помощью конструкции ВЫРАЗИТЬ также оканчиваются неудачей.
В этой статье мы подробно разберем внутренние механизмы работы платформы 1С с текстовыми полями, выясним, почему СУБД физически не может выполнить такое сравнение, и рассмотрим несколько эффективных и быстрых способов решения этой проблемы.
Для того чтобы понять природу ошибки, нам необходимо заглянуть под капот платформы 1С:Предприятие и посмотреть, как она взаимодействует с базами данных (будь то MS SQL Server, PostgreSQL, IBM DB2 или Oracle). Каждая объектная таблица в информационной базе (справочники, документы, бизнес-процессы) имеет виртуальное поле Представление.
Важно понимать, что поля «Представление» физически не существует в таблицах СУБД. Это виртуальная конструкция (макрос) самой платформы 1С. Когда мы пишем запрос и выбираем поле Представление, СУБД не считывает готовую строку из базы. Вместо этого платформа 1С на лету трансформирует наше обращение в выборку нескольких реальных полей (например, для справочников это обычно связка полей Код + Наименование, а для документов — Номер + Дата).
Окончательное преобразование этих данных в единую красивую текстовую строку происходит уже после того, как СУБД вернула результат запроса. Платформа 1С делает это на сервере приложений или на клиенте, учитывая локальные настройки сессии пользователя (например, язык интерфейса, часовой пояс и форматы вывода чисел/дат).
Поскольку на момент выполнения SQL-запроса в СУБД готовой строки представления еще не существует, СУБД физически не может применить к ней логические операции, такие как:
=) или неравенство (<>);>=, <=);ПОДОБНО);ГРУППИРОВАТЬ ПО);УПОРЯДОЧИТЬ ПО);РАЗЛИЧНЫЕ).Попытка использовать поле Представление в секции ГДЕ или ПО (при соединении таблиц) неизбежно приводит к аварийной остановке выполнения запроса.
Иногда разработчики пытаются обойти проблему, используя явное приведение типов в запросе, надеясь преобразовать виртуальное представление в строку фиксированной длины. Выглядит это примерно так:
|ГДЕ
| ВЫРАЗИТЬ(ИнвентарныеНомераОС.Представление КАК СТРОКА(30)) = &ИнвентНомер
Этот код также вернет ошибку несовместимости типов. Оператор ВЫРАЗИТЬ транслируется в SQL-функции приведения типов (такие как CAST или CONVERT). Данный оператор ожидает на вход реальное поле базы данных.
Например, ВЫРАЗИТЬ отлично работает с реквизитами типа Строка неограниченной длины (такими как комментарии или текстовые описания документов). Мы можем ограничить длину такой строки в запросе, чтобы использовать ее в условиях сравнения или группировках:
// Это корректный и работающий код
|ГДЕ
| ВЫРАЗИТЬ(СправочникНоменклатура.Описание КАК СТРОКА(100)) = &ПоисковыйТекст
Но поскольку Представление не является реальным полем базы данных, платформа выдает ошибку совместимости типов еще на этапе трансляции запроса из языка 1С в язык SQL. По этой же причине к представлению нельзя применить стандартную функцию ПОДСТРОКА().
Рассмотрим несколько практических способов обойти это ограничение, от простых и быстрых до наиболее правильных с точки зрения производительности системы.
Поскольку представление объекта чаще всего строится на основе его кода или наименования, мы можем заменить виртуальное поле Представление в запросе на реальный реквизит, который хранится в базе данных как строка фиксированной длины.
Для этого нам нужно открыть конфигуратор и посмотреть, какое «Основное представление» установлено для исследуемого справочника в свойствах объекта:
Наименование.Код.Давайте перепишем исходный запрос, заменив сравнение представления на сравнение с кодом справочника:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОсновныеСредства.Ссылка КАК Ссылка,
| ИнвентарныеНомераОС.Ссылка КАК ИнвентарныйНомер,
| ИнвентарныеНомераОС.Код КАК КодИнвентарногоНомера
|ИЗ
| Справочник.ОсновныеСредства КАК ОсновныеСредства
| ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ИнвентарныеНомераОС КАК ИнвентарныеНомераОС
| ПО ОсновныеСредства.Ссылка = ИнвентарныеНомераОС.ОС
|ГДЕ
| ОсновныеСредства.Ссылка = &Объект
| И ИнвентарныеНомераОС.Код = &ИнвентНомер"; // Сравниваем с реальным строковым полем
Запрос.УстановитьПараметр("Объект", СтрокаТаблицы.Товар.НаименованиеОбъекта);
// Передаем строку, содержащую код инвентарного номера
Запрос.УстановитьПараметр("ИнвентНомер", СтрокаТаблицы.Товар.ИнвентарныйНомер);
РезультатЗапроса = Запрос.Выполнить();
Этот способ отлично работает, если тип данных в вашей таблице-источнике (например, в ТЗ) гарантированно строковый, и он соответствует коду или наименованию в базе данных.
Сравнение текстовых строк в базах данных — это всегда ресурсоемкая операция. Если таблица справочника содержит сотни тысяч записей, поиск по текстовому полю (особенно если по нему не построен индекс) будет выполняться медленно.
Наиболее правильным архитектурным решением является предварительный поиск ссылки на объект во встроенном языке 1С с последующей передачей готовой ссылки в параметр запроса. Сравнение уникальных идентификаторов (ссылок) на уровне СУБД происходит мгновенно.
Давайте реализуем этот подход по шагам:
// Шаг 1. Находим ссылку на инвентарный номер по его коду (или наименованию) во встроенном языке
КодДляПоиска = СтрокаТаблицы.Товар.ИнвентарныйНомер;
СсылкаНаИнвНомер = Справочники.ИнвентарныеНомераОС.НайтиПоКоду(КодДляПоиска);
// Шаг 2. Проверяем, найден ли объект в базе данных
Если СсылкаНаИнвНомер.Пустая() Тогда
Сообщить("Не найден инвентарный номер с кодом: " + КодДляПоиска);
Возврат;
КонецЕсли;
// Шаг 3. Передаем в запрос готовую ссылку вместо строки
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОсновныеСредства.Ссылка КАК Ссылка,
| ИнвентарныеНомераОС.Ссылка КАК ИнвентарныйНомер
|ИЗ
| Справочник.ОсновныеСредства КАК ОсновныеСредства
| ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ИнвентарныеНомераОС КАК ИнвентарныеНомераОС
| ПО ОсновныеСредства.Ссылка = ИнвентарныеНомераОС.ОС
|ГДЕ
| ОсновныеСредства.Ссылка = &Объект
| И ИнвентарныеНомераОС.Ссылка = &ИнвентНомерСсылка"; // Сравнение по ссылкам работает максимально быстро
Запрос.УстановитьПараметр("Объект", СтрокаТаблицы.Товар.НаименованиеОбъекта);
Запрос.УстановитьПараметр("ИнвентНомерСсылка", СсылкаНаИнвНомер);
РезультатЗапроса = Запрос.Выполнить();
Этот подход не только решает проблему с ошибкой сравнения, но и существенно повышает скорость работы системы, снижая нагрузку на процессор сервера СУБД.
Иногда возникают сложные ситуации, когда представление объекта формируется динамически по кастомному шаблону (например, сочетание кода, наименования и какого-то дополнительного реквизита, разделенных дефисом: "00125 - Системный блок (Новый)").
Если нам нужно сравнить именно такое сложное представление, а в параметре запроса передается строка, собранная по этому шаблону, мы можем собрать точно такую же строку внутри запроса с помощью оператора сложения строк (+). Полученное выражение будет являться реальной строкой, и СУБД успешно выполнит сравнение.
Проанализируем пример построения такого условия:
|ГДЕ
| (ИнвентарныеНомераОС.Код + " - " + ИнвентарныеНомераОС.Наименование) = &СложноеПредставление
При использовании этого метода будьте аккуратны с типами данных: все складываемые части выражения должны быть строго строкового типа, иначе запрос завершится ошибкой выполнения из-за несовместимости типов при сложении.
При написании запросов в 1С всегда помните о природе виртуальных полей. Поле Представление и функция ПРЕДСТАВЛЕНИЕ() предназначены исключительно для вывода информации пользователю в финальном результате запроса.
Для любых логических операций (сравнение, фильтрация, соединения, группировки) используйте только реальные поля таблиц базы данных — Ссылка, Код или Наименование. Это сбережет ваше время при отладке кода и гарантирует стабильную и быструю работу вашей конфигурации.