Как предотвратить обрезание строк и настроить поиск по длинным полям в СКД?

При разработке отчетов на базе системы компоновки данных (СКД) разработчики часто сталкиваются с ситуацией, когда строковые реквизиты большой длины (например, адреса, комментарии или описания длиной 500 символов и более) обрезаются при выводе или при поиске. В результате отбор по условию ПОДОБНО перестает находить данные, если искомый фрагмент находится за пределами первых 100 символов строки. Проанализируем причины такого поведения платформы «1С:Предприятие» и подробно рассмотрим способы решения этой проблемы.

Почему СКД усекает строки и параметры поиска

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

1. Автоматическое определение типа параметров: Если на вкладке «Параметры» схемы компоновки данных тип параметра оставлен неопределенным или не задана максимальная длина, платформа назначает параметру фиксированную длину (как правило, 100 символов). Введенный пользователем текст усекается еще до момента передачи в СУБД.
2. Формирование условий с конкатенацией строк в секции расширения: Конструкция вида {ГДЕ (Таблица.Адрес ПОДОБНО "%" + &Параметр + "%")} может приводить к неоднозначному определению типа результирующего выражения на стороне СУБД, что влечет за собой принудительное усечение шаблона.
3. Настройки отображения в табличном документе: Визуальное обрезание текста в отчете может быть связано с ограничением ширины колонок и отсутствием свойства автоматического переноса текста в макете или оформлении полей.

Способ 1. Явная типизация параметра в схеме компоновки

Разберем по шагам базовое исправление, которое необходимо выполнить в первую очередь:

1. Откроем схему компоновки данных и перейдем на вкладку «Параметры».
2. Найдем параметр, отвечающий за поиск по строке (например, АдресЗаказчика).
3. В колонке «Тип» снимем автоматическое определение и выберем тип Строка.
4. В свойствах типа укажем точную длину (например, 500) или установим значение 0 (строка неограниченной длины).

Это гарантирует, что значение, введенное пользователем в настройках отчета или на форме, не будет обрезано до 100 символов при передаче в запрос.

Способ 2. Разделение параметра ввода и расчетного шаблона ПОДОБНО

Если условие фильтрации передается непосредственно в текст запроса, правильнее вычислять шаблон поиска с символами % отдельно с помощью выражений параметров СКД. Разберем этот вариант подробнее:

1. В тексте запроса изменим условие в блоке динамических фильтров:

ВЫБРАТЬ
    ОбщийВодаКанал.Заказчик КАК Заказчик,
    ОбщийВодаКанал.АдресЗаказчика КАК АдресЗаказчика,
    ОбщийВодаКанал.ХозНужд КАК ХозНужд,
    ОбщийВодаКанал.Стоки КАК Стоки
ИЗ
    РегистрСведений.ОбщийВодаКанал КАК ОбщийВодаКанал
ГДЕ
    ОбщийВодаКанал.Заказчик.ФизЮр = ИСТИНА
    И ОбщийВодаКанал.Период МЕЖДУ &ДатаНач И &ДатаКон
    И ОбщийВодаКанал.Стоки >= &Норма1
    И ОбщийВодаКанал.ХозНужд >= &Норма2
    {ГДЕ (ОбщийВодаКанал.АдресЗаказчика ПОДОБНО &ШаблонАдреса)}

1. Перейдем на вкладку «Параметры» схемы компоновки данных.
2. Создадим пользовательский параметр АдресПоиска с типом Строка(500).
3. Создадим служебный параметр ШаблонАдреса с типом Строка(502).
4. Для параметра ШаблонАдреса установим флаг «Ограничение доступности» (чтобы скрыть его от пользователя), а в колонке «Выражение» зададим формулу: "%" + &АдресПоиска + "%".
5. В колонке «Условие использования» для ШаблонАдреса укажем: ЗначениеЗаполнено(&АдресПоиска).

Такой подход полностью исключает ошибки динамической типизации на уровне СУБД и сохраняет полную длину строки поиска.

Способ 3. Использование штатных отборов СКД вместо ручного условия в запросе

Наиболее надежный и рекомендуемый стандартами разработки способ — доверить построение условий сравнения самой системе компоновки данных. Посмотрим, как это реализовать:

1. Уберем конструкцию ПОДОБНО из текста запроса и оставим поле доступным для компоновки:

ВЫБРАТЬ
    ОбщийВодаКанал.Заказчик КАК Заказчик,
    ВЫРАЗИТЬ(ОбщийВодаКанал.АдресЗаказчика КАК СТРОКА(500)) КАК АдресЗаказчика,
    ОбщийВодаКанал.ХозНужд КАК ХозНужд,
    ОбщийВодаКанал.Стоки КАК Стоки
ИЗ
    РегистрСведений.ОбщийВодаКанал КАК ОбщийВодаКанал
ГДЕ
    ОбщийВодаКанал.Заказчик.ФизЮр = ИСТИНА
    И ОбщийВодаКанал.Период МЕЖДУ &ДатаНач И &ДатаКон
    И ОбщийВодаКанал.Стоки >= &Норма1
    И ОбщийВодаКанал.ХозНужд >= &Норма2

1. Перейдем на вкладку «Настройки» в раздел «Отбор».
2. Добавим новый элемент отбора: левое значение — АдресЗаказчика, вид сравнения — «Содержит», правое значение — необходимое значение для поиска.
3. При необходимости вынесем этот отбор в состав пользовательских настроек отчета.

При использовании вида сравнения «Содержит» СКД автоматически сгенерирует корректный SQL-запрос с шаблонами подстановки, учитывая точный тип поля источника данных.

Способ 4. Настройка отображения полного текста поля в отчете

Если данные в базе находятся полностью, но обрезаются визуально при формировании печатной формы, настроим условное оформление:

1. На вкладке «Наборы данных» выберем поле АдресЗаказчика.
2. В колонке «Оформление» зададим параметр «Размещение» со значением Переносить.
3. Дополнительно можно указать параметр «Минимальная ширина» или «Максимальная ширина» для корректного распределения пространства в табличном документе.

Рекомендации по оптимизации производительности

Важно помнить, что поиск с использованием оператора ПОДОБНО "%...%" по длинным строковым полям приводит к полному сканированию всей таблицы базы данных (Index/Table Scan), игнорируя существующие индексы. Если объем данных в регистре велик, такой отчет может выполняться медленно и вызывать блокировки. Для высоконагруженных систем рекомендуется:

1. Использовать встроенный механизм Полнотекстового поиска платформы «1С:Предприятие».
2. Хранить адресные сведения в структурированном виде (декомпозировать на регион, город, улицу и дом или интегрировать с адресными классификаторами ФИАС/ГАР).