Является ли элемент справочника "Подразделения" родителем для другого элемента #463937

Доброго всем времени суток. Столкнулся с проблемой получения всех родителей для элемента справочника "Подразделения". В форуме описывалась противоположная проблема: "Принадлежность элемента группе номенклатуры" Там же приводится пример кода на языке запросов. Вот он: ВЫБОР    КОГДА Номенклатура.Ссылка В ИЕРАРХИИ (&СписокЗначений) Мне же требуется противоположный случай. По аналогии нужно делать так: Но выдается ошибка. Помогите пожалуйста разобраться в проблеме

По аналогии и не получиться, через подзапрос надо делать.

А чего там разбираться? Текст ошибки перевести? Давай все незнакомые слова сюда, расскажу.

Выдает ошибку: Неверные параметры "В ИЕРАРХИИ" КОГДА &СписокЗначений В ИЕРАРХИИ ( <<?>>Подразделения.Ссылка )

Подскажите, пожалуйста, через какой подзапрос необходимо делать....

опиши задачу более подробно, без примеров типа "надо сделать вот так, но только наоборот и это должно быть тут"

реализуйте через LEFT JOIN с количеством уровней максимально возможным ну например 100 Вобщем не использование ограничения кол-ва вложенности - зло, как и любая непределенность.

Задача: Получить всех потомков зная родителя. Т.е. На вход дается список подразделений (Родители). На выходи должны получить таблицу, состоящую из двух колонок: Родитель, Потомки. Причем потомки не только первого уровня, а все уровни (так сказать, до последнего колена). Пример: Исходные данные: На выходе:

Если же на входе дается список: То результат должен выглядеть так: Цех № 1    Цех № 1 Цех № 1    Участок № 11

ну так Вам подходит в иерархии А вы задачу обозначили наоборот

Дело в том что если использовать В ИЕРАРХИИ то результат будет таков: На входе: Цех № 1 На выходе:

Честно признаться уже ум за разум заходит. Вроде должно быть все просто... Но вот правильный запрос написать не получается...

код в сдудию

Заранее прошу прошение за английский, ибо пишу на английском... SELECT    NormativeExpensesCostsSliceLast.Division AS DivisionParent,    Divisions.Ref AS DivisionChild,    NormativeExpensesCostsSliceLast.Nomenclature,    NormativeExpensesCostsSliceLast.Characteristic,    NormativeExpensesCostsSliceLast.SumManagement FROM    InformationRegister.NormativeExpensesCosts.SliceLast ( &Period, Organization IN ( &Organization ) AND ( Nomenclature = &Nomenclature ) ) AS NormativeExpensesCostsSliceLast        LEFT JOIN Catalog.Divisions AS Divisions                                (                                FROM                                    InformationRegister.NormativeExpensesCosts.SliceLast ( &Period, Organization IN ( &Organization ) AND ( Nomenclature = &Nomenclature ) ) AS NormativeExpensesCostsSliceLast

Смотрел книгу "Описание встроенного языка" Часть 2. Там описывается: Смотрим что собой представляет <Логическое выражение>: Смотрим что собой представляет <Список значений>: Смотрим что собой представляет <Выражение>: <Выражение>    <Разыменование поля> | Смотрим что собой представляет <Разыменование поля>: <Разыменование поля>    [Таблица.]<Имя поля>[.<Имя поля>[...]] От суда следует что теоретически можно использовать ON Divisions.Ref IN HIERARCHY ( NormativeExpensesCostsSliceLast.Division ) Но как ни крути, на практике получается что в иерархии нельзя использовать разыменование полей. Или я что-то не так делаю? Помогите, понять в чем дело или предложите другой вариант решения проблемы.

так у Вас нет условия объединения для  LEFT JOIN такчто работает CROSS. к тому же Вы текст запроса один показали а резултат выборки - от другого. лучше разбейте для отладки на подзадачи (подзапросы)

Строго говоря в задаче нужно использовать ВНУТРЕННЕЕ СОЕДИНЕНИЕ (INNER JOIN) InformationRegister.NormativeExpensesCosts.SliceLast ( &Period, Organization IN ( &Organization ) AND ( Nomenclature = &Nomenclature ) ) AS NormativeExpensesCostsSliceLast        INNER JOIN Catalog.Divisions AS Divisions        ON Divisions.Ref IN HIERARCHY ( NormativeExpensesCostsSliceLast.Division ) Но все равно выходит ошибка. Просто хотелось бы чтобы в результате запроса отображались только те подразделения из второй таблицы (Divisions) (потомки), которые имеют родителей-предков из первой таблицы (NormativeExpensesCostsSliceLast). Опишу более детально, что конкретно требуется: В регистре сведений "Нормативная стоимость затрат" храниться нормативная цена затрат, которая устанавливается на конкретное подразделение. В реальности, эта нормативная цена распространяется и на под-подразделения. Этим запросом хотелось бы получить, какая цена действует на конкретном под-подразделении

тут действует припринцип "подальше положешь - поближе возьмешь" так что первым запросом во временную таблу получите данные, а вторым на основе первого через в "иерархии" получите подчиненых. воообщем получается сложная структура. основаная на алгоритме а не на данных. что есть противоположность реляционной модели. и мне кажется лучше хранить всю информацию в развернутом виде. при условии,что бд не файловая (иначе будет ограничение в 4 гига на таблицу) к тому же будет "гибкость" в назначении стоимости затрат.

Я все больше убеждаюсь в том, что разыменованные поля в конструкции В ИЕРАРХИИ не получается использовать. Например, в результате под запроса я получил таблицу, состоящею из двух колонок: Родитель, Потомк. Эту таблицу можно отфильтровать по условию. Приблизительно вот так:    * ИЗ    (    ИЗ Выходит ошибка. Выше я говорил о том, что в описании разрешается использовать разыменованные поля в конструкции В ИЕРАРХИИ ( <Разыменование поля> ) Ответьте мне пожалуйста, что Вы думаете по этому поводу... Что я делаю не так? Может есть альтернативное решение задачи... (через язык запросов)

Скорее всего нужно будет писать алгоритм... А так хотелось через запрос... :( Ну...что же. Сделаем через алгоритм...

через "в иерархии" будет работать как описано в на крайний случай, сделайте как в а под алгоритмом я понимаю неочевидную связь родитель - потомок. те об условии (алгоритме), что свойство родителя применимо к потомку определено только на уровне Вашего знания. Нужно, по возможности, не использовать такие НЕявные связи(запутанные отношения). тк поддержка явных реляций намного надежней. попросту, если вам захочется изменить связь - придется переделывать кучу кода и можно где-то упустить. поддержка кучи запутанных алгоритмов - очень дорогая. тк связи могут запутываться. А применение сразу двух запутанностей HIERARCHY и SliceLast не гуд.