Нужно получить из 3-х наборов A,B и C выходной набор, при этом к набору присоединить наборы B и C по аналогии запроса -
... ИЗ А КАК А ЛЕВОЕ СОЕДИНЕНИЕ В КАК В По А.а=B.а
ЛЕВОЕ СОЕДИНЕНИЕ С КАК С По А.а=С.а ....

Можно ли такое соединение получить в СКД?

Бьюсь - все никак не получается. В СКД Указываю источник связи - набор A во всех строках, естественно приемник соответсвенно В и С. В результате выдает что используются поля несвязанных наборов. Если поменять местами источник и приемние - не ругается, но выборка естественно не верная (пустая).

Неужели в СКД такое невозможно? Что-то не догоняю

в скд возможно тока левое соединение

Так мне и нужно только левое соединение, единственное к набору а присоединить несколько наборов. Или если несколько наборов то это уже не левое соединение?

(0) можно соединить, что то вы не то делаете

Вы случайно не пытаетесь в вычисляемых полях использовать поля В и С?

Объединение же есть

(4) Не я первый с эти бодаюсь, в инете встречаются вопросы только не нашел ответов. Я уже убрал всякие вычисляемые поля. Просто к набору А надо присоединить 2 набора B и С. Естественно наборы B и C между собой не связаны. В отчет нужно вывести все поля. Вот тут и спотыкается. Блин в СКД куча всего - типа и иерархию строит, и итоги считает правильно и т.д. и т.п. А элементарное соединение произвести не позволяет. Что уж проще то. Не пойму разработчика

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

(6) посмотрите в типовых должен быть отчет "Свод начисленой зарплаты организации", посмотрите там

(6) на крайний случай можно сделать в запросе левое соединение

(6)-(7) Попробовал создать как вы делали, действительно ругается. надо будет поковырять как его обойти

(10) К сожалению обход через задний проход! И это при всем том, что СКД позиционируется как шаг (если не два) вперед. В простых ситуациях его можно создать. А вот если побольше наборов данных - то заколебаешься все со всеми связывать (на сей момент я свою проблему кое-как решил, исключительно только благодаря тому, что смог описать ненужную связь между наборами B и С, нашлося реквизит, за который смог зацепиться) И почему разработчиками сделана такая проблема в этом - мне например совсем не понятно! Ну хоть стреляйте. Ведь потребности в этом больше чем предостаточно. И не всегда решение можно сделать через соединение в запросе. А сложност в реализации соединения наборов - ну никакой, детский  лепет по сравнению с реализацией всего остального что присутсвует в СКД.

(11) ну на счет мелочи, столько раз мне клиенты говорили - так ту всего лишь кнопочку добавить и приходилось им объяснять, что сама по себе кнопочка ничего не значит, а вот пару сотен кода, которые нужно к ней прикрутить не пишутся за полчаса

(12) ага. только данная ситуация - фундаментальная, а не прикрутить кнопочку, да и СКД уж сколько лет как вроде существует и вроде как развивается. Да и уйму моментов можно было бы обойти, если бы например внешние наборы данных можно было использовать в запросах в СКД. Вот например что сложного в этом. Получается просто в запрос внешнюю таблицу загрузить можно, а в СКД - нет. Ну простое решение в лоб, если уж там это как-то все поперек и не срастается - сделать еще один вид набора данных исключительно для ввода внешней информации, или сделать возможность в параметры загружать таблицу. Затраты на реализацию - минимум - эффект на лицо. В большинстве моментов не надо было бы делать объединений и соединений наборов, а все (ну или почти все) можно было бы сделать на единственном запросе. Ладно - это так из серии "о наболевшем"

(0) попробуй в СКД добавить связь B.a=C.a

(13) так в СКД есть набор данных объект - это и есть внешняя таблица

(14) Не всегда такое возможно. Для конкретной текущей ситуации я так и сделал (нашлось к чему привязаться). Опять же - этот лишняя связь!! (с точки зрения построения выходного набора данных). Например в строке набора А есть 2 различных ссылочных поля, по каждому из которых и получаем связи к наборам B и C соответственно. Сами наборы B и C - между собой не имеют общих реквизитов и связать их между собой не по чем. Но наборы связаны посредством набора A. Вот тут и вилы - СКД не позволяет такое использование

(15) - только этот набор в запрос не запихнешь, и как раз необходимость его использования и приводит к вышеописанным граблям

(14) я догадываюсь приблизительно откуда растут ноги на запрет такого использования - только по-моему это излишне

(16)-(18) С другой стороны, Если вы выбираете поля наборов В и С, откуда компоновка знает как их связать? Как нам на курсах объяснили, компоновка  извлекает из базы результат всех запросов отдельно а потом соединяет. И если вы выбрали в настрйоках для вывода поля таблицы С, то он не будет делать запрос по таблице В и А.

(19) я приблизительно так и думаю о причинах. Но вот тут и возникают колизии, а именно - "ЕСЛИ!! там кто-то чего го сделает" и "система извлекает результаты отдельно а потом связывает". То бишь все идет последовательно как и должно быть:  получаем выходные несвязанные таблицы (пусть согласно того что там пофильтровали и т.п.) ЗАТЕМ!!! соединяем таблицы согласно связей, и только ПОТОМ!!! начинаем обрабатывать выходную таблицу (группировать и т.п.). Так что мешает после объединения таблиц если что-то не так проконтролировать и ругнуться или вывести криво (ну раз криво пользователь что-то накладывает - мало ли что штатно можно сделать такое - что положит работу отчета и без этого). Зачем блокировать сразу?! А если пользователь ничего не меняет - то что не будем делать, поскольку он может изменить?! Бред. Ведь логика необходимости получения наборов B и C уже продиктована наличием полей из этих наборов в выходной таблице. Логика связи наборов никак не нарушает работу СКД в данной части

(20) а можно создавать таки соединение одного набора с несколькими. Есть типовый отчет в украинской конфигурации могу прислать. В чем фишка не понял, но я попробовал связать три набора, то пока для числового ресурса регистра сведений не определил его как ресурс, он выдавал ту же ошибку.

(21)+ в общем получилось связать три источника без лишнего соединения

(21) - если не сложно - буду рад отчету - попробую по аналогии (мыло в профиле). Кстати ресурсы я не определял - они мне в данной задаче не нужны, нужны просто детальные записи. Может загвоздка где нибудь и в этом.

Подпишусь из-за интереса :)

Очень редко использую объединения/соединения, почему-то всегда в запросе все вытворяю :(

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

(25) Отправил

(26) Спасибо. Получил. Правда мало чем помогло. Но вот уже за 2 дня экспериментов выяснились некоторые моменты. Если есть числовые поля - то они могут быть ТОЛЬКО В РЕСУРСАХ. Иначе ошибка об использовании полей из несвязанных наборов. Строковые и ссылочные поля выводятся. То есть связь вроде как работает, но начинает конфликтовать числовые поля из разных наборов. Вот такие пироги. (и чем блин число хуже той же строки?!!). Ну и намудрили. По сути какая разница какого типа поле, ума не приложу. Сегодня надоело уже бодаться, завтра проведу еще ряд экспериментов.

Короче так толком связь в СКД и не работает! Можно соединить любое количество наборов, но вывести можно только ресурсы из всех наборов и поля из основного набора и из одного набора из правой части соединения. Вывести поля из разных наборов - невозможно, использовать ресурсы из разных наборов в вычисляемых полях - тоже невозможно! Короче лажа и полноценного соединения не получить