При разработке сложных запросов в системе 1С:Предприятие мы периодически сталкиваемся с ситуациями, когда синтаксически верный код приводит к неожиданным ошибкам платформы. Одной из таких неприятных ошибок является сообщение "выход за пределы размерности результата". Чтобы своевременно выявлять подобные проблемы, полезно проводить регулярный анализ конфигураций и расширений на наличие ошибок. Характерно, что в консолидации SQL (например, в Profiler) запрос может выполняться без ошибок, но платформа 1С аварийно завершает работу с ним.
В этой статье мы подробно разберем, почему возникает данная ошибка, как она связана с механизмом SDBL и, самое главное, рассмотрим проверенные способы изменения текста запроса, что упростит работу разработчика при написании запросов и обеспечит стабильность кода.
Давайте рассмотрим типичный сценарий, при котором возникает эта ошибка. У нас есть задача выбрать определенное количество записей (например, первые 10), поместить их во временную таблицу и при этом упорядочить результат по иерархии.
Пример кода, вызывающего сбой, выглядит следующим образом:
ВЫБРАТЬ ПЕРВЫЕ 10
Номенклатура.Код КАК Код,
Номенклатура.Наименование КАК Наименование
ПОМЕСТИТЬ ВТ_Результат
ИЗ
Справочник.Номенклатура КАК Номенклатура
УПОРЯДОЧИТЬ ПО
Наименование ИЕРАРХИЯ
На первый взгляд, запрос кажется логичным. Мы хотим получить выборку, сразу отсортированную иерархически, и сохранить её для дальнейшей обработки. Однако при выполнении этого кода платформа выдает ошибку: "выход за пределы размерности результата".
Давайте проанализируем, почему это происходит. Проблема кроется в сочетании трех ключевых операторов:
ПОМЕСТИТЬ (создание временной таблицы);ПЕРВЫЕ (ограничение выборки);ИЕРАРХИЯ (построение дерева).Ошибка возникает на уровне SDBL (Scheme Data Base Layer) — прослойки между 1С и SQL Server. Когда мы используем конструкцию УПОРЯДОЧИТЬ ПО ... ИЕРАРХИЯ, платформа неявно добавляет к результату служебные поля. Если ваша задача сложнее и требует более глубокой работы со структурами, может потребоваться интерактивное формирование текста запроса для получения родителей всех уровней. Механизм SDBL не может корректно сопоставить динамически расширяющийся набор полей иерархии с фиксированной структурой временной таблицы, особенно когда выборка ограничена оператором ПЕРВЫЕ.
Самый надежный и архитектурно верный способ избежать этой ошибки — разделить получение данных и построение иерархии. Хранить иерархически упорядоченные данные во временной таблице бессмысленно, так как реляционные таблицы по своей природе неупорядочены. Порядок гарантируется только при выборке (SELECT) с явным указанием сортировки.
Давайте перепишем наш запрос, разбив его на два этапа.
Этап 1: Получение данных во временную таблицу
На этом шаге мы просто отбираем нужные записи, используя ПЕРВЫЕ, но убираем ключевое слово ИЕРАРХИЯ. Стоит отметить, что в современных версиях платформы (8.3.25+) стало доступно добавление данных в существующую временную таблицу, что дает еще больше гибкости при подготовке наборов данных.
ВЫБРАТЬ ПЕРВЫЕ 10
Номенклатура.Код КАК Код,
Номенклатура.Наименование КАК Наименование,
Номенклатура.Родитель КАК Родитель // Если нужно для дальнейшей иерархии
ПОМЕСТИТЬ ВТ_ИсходныеДанные
ИЗ
Справочник.Номенклатура КАК Номенклатура
УПОРЯДОЧИТЬ ПО
Наименование
;
Теперь данные надежно сохранены во временной таблице ВТ_ИсходныеДанные. Ошибки не возникнет, так как структура таблицы простая и понятная платформе.
Этап 2: Выборка с иерархией
Теперь, когда нам нужно получить результат (например, для вывода в отчет или дерево значений), мы обращаемся к временной таблице и применяем иерархию.
ВЫБРАТЬ
Т.Код,
Т.Наименование
ИЗ
ВТ_ИсходныеДанные КАК Т
УПОРЯДОЧИТЬ ПО
Т.Наименование ИЕРАРХИЯ
Такой подход полностью устраняет конфликт в SDBL, так как иерархия строится уже на этапе чтения готового набора данных, а не в момент вставки (INSERT) в базу данных.
Если логика вашего алгоритма требует выполнения действия одним пакетом или структура запроса очень сложна, можно попробовать обернуть выборку во вложенный запрос. Это заставляет платформу сначала сформировать иерархическую выборку во внутреннем представлении, а затем результат поместить в таблицу.
Посмотрим, как это выглядит на практике:
ВЫБРАТЬ
ВложенныйЗапрос.Код,
ВложенныйЗапрос.Наименование
ПОМЕСТИТЬ ВТ_Результат
ИЗ
(ВЫБРАТЬ ПЕРВЫЕ 10
Номенклатура.Код КАК Код,
Номенклатура.Наименование КАК Наименование
ИЗ
Справочник.Номенклатура КАК Номенклатура
УПОРЯДОЧИТЬ ПО
Наименование ИЕРАРХИЯ) КАК ВложенныйЗапрос
В данном случае мы изолируем конструкцию ПЕРВЫЕ ... ИЕРАРХИЯ внутри подзапроса. Для быстрой проверки и отладки подобных конструкций отлично подойдет консоль запросов с полной поддержкой временных таблиц. Однако, стоит помнить, что использование вложенных запросов может быть менее читаемым и иногда менее производительным, чем использование временных таблиц.
Давайте обсудим важный теоретический аспект. Использование конструкции ИЕРАРХИЯ при помещении данных во временную таблицу часто нарушает общепринятые стандарты и методики разработки конфигураций 1С и является избыточным.
ТОP (ПЕРВЫЕ) и иерархических итогов является "тонким местом" транслятора запросов 1С.Подводя итог нашему исследованию ошибки "выход за пределы размерности результата", сформулируем основные правила:
1. Если вы видите эту ошибку, первым делом проверьте текст запроса на наличие комбинации ПОМЕСТИТЬ, ПЕРВЫЕ и ИЕРАРХИЯ.
2. Лучшая практика — никогда не использовать ИЕРАРХИЯ при создании временных таблиц. Временные таблицы должны хранить "сырые" или предварительно обработанные плоские данные.
3. Применяйте ключевое слово ИЕРАРХИЯ только в конечном запросе, который выбирает данные для пользователя или выгрузки.
Соблюдение этих простых правил позволит вам избежать трудноуловимых ошибок платформы и сделает ваш код более стабильным и предсказуемым.