Привет, ребята.

Мне нужно вывести наружу элемент второго уровня иерархии справочника, который является непрямым родителем заданного элемента (т.е. между ними может быть сколько угодно элементов иерархии). Начал решать задачу путем получения списка элементов второго уровня из объектной таблицы справочника и сравнения с имеющимся элементом по условию "В ИЕРАРХИИ", но платформа послала меня далеко. Прошу вашей помощи, как мне сделать все как надо, не теряя при этом в производительности? Хватит и намека =)

если неограниченная иерархия, то запросом никак не сделаешь

(1) т.е., тут только метод старого доброго молотка и костыля?

Господа, а не это ли моя панацея?

СправочникСсылка.<Имя справочника> (CatalogRef.<Имя справочника>)
ПринадлежитЭлементу (BelongsToItem)
Синтаксис:

ПринадлежитЭлементу(<Элемент>)
Параметры:

<Элемент> (обязательный)

Тип: СправочникСсылка.
Группа (или элемент для иерархического справочника с иерархией элементов), для которой определяется принадлежность элемента.
Возвращаемое значение:

Тип: Булево.
Истина - элемент подчинен группе; Ложь - в противном случае.
Если в качестве параметра указать сам элемент, то Ложь.
Описание:

Определяет подчиненность элемента справочника группе с учетом всех уровней иерархии.

Доступность:

Сервер, толстый клиент, внешнее соединение.
Примечание:

Определяет подчиненность группе непосредственно на момент вызова метода путем последовательного считывания всех вышестоящих элементов.
Пример:

Если ОбъектСсылка.ПринадлежитЭлементу(ЭлементСсылка) Тогда
    Сообщить("Принадлежит");
КонецЕсли;

"путем последовательного считывания всех вышестоящих элементов" - уффф, производительность падает...

В общем случае я вижу только трудный путь
1) запросами в цикле сгенерить временную ТЗ, содержащую структуру папок со всеми вышестоящими родителями и уровнями (кво запросов получится по количеству уровней).
2) ну а соединением 1) с родителями реальных элементов легко уже будет сделать любые нужные отборы

(5) Думаю, я выберу путь, при котором запросом получу набор нужных элементов иерархии, потом другим запросом набор необходимых данных, после чего уже в коде буду сравнивать с помощью указанного выше метода, но спасибо.

ЗЫ я не верю в запросы в цикле, особенно на управляемом интерфейсе =)

(6) Ну, или не в цикле. Одним запросом получить все папки, серверным алгоритмом переварить эти данные и создать нужную ТЗ, после чего залить её во временную таблицу и дальше 2)
Хотя, в принципе это практически тоже самое будет, что ты предлагаешь. Только удобнее для всяких там СКД.
ЗЫ. "Запросы в цикле" - это просто уже мем, который пугает слабых духом одним названием. А УФ тут вообще не причем, речь о серверной стороне.

(6) А если ты про ПринадлежитЭлементу() в качестве "указанного выше метода", то у тебя как раз и получатся "запросы в цикле" в своем худшем варианте.

(8)Да я понимаю, но лучше метода нет, к сожалению. Радует только, что фирма небольшая и у них не предвидится критических объемов.
Речь идет не только о серверной стороне, это перекрученная печатная форма и в ней могут быть вызовы с клиента. Поэтому запросы в цикле лучше исключить, как я понимаю, метод ПринадлежитЭлементу() хоть как-то оптимизирован и в нем уже исключены ошибки, которые я могу допустить. Ну и да, скорее всего я ошибаюсь.

Пишем петицию в 1С с требованием задействовать рекурсивные запросы (которые SQL понимает, разумеется) в своём синтаксисе.

(10) Вот да, так их не хватает, что иногда прямо даже обидно

(10) Если будет такая петиция, удостойте плз ссылкой, добавим несколько галочек с коллегами =)

(12) Это такой чёрный юмор. Да и положить им на петиции.

(10) :) Важно понимать, что у разных SQL разные методы работы с иерархией...

(14) штоа? у каких ещё "разных SQL"?

(15) Подразумеваются различия диалектов SQL в разных СУБД.

(16) CTE уже по-моему все (из 1С-совместимых) поддерживают, и далеко не первый год.

Впрочем, это ж всё равно был юмор.
Такие улучшения не будут вводиться вовсе не по причине отсутствия поддержки каким-то SQL-сервером.
Ведь коррелирующие подзапросы всеми серверами поддерживаются, чуть ли не с рождения, однако...