Существуют определенные расчеты, которые делаются запросами. Расчетов очень много, запросов соответственно тоже.
Грубо говоря 80% расчетов и запросов им соответствующих похожи вот чем:
Блок запроса шапка состоящий из 4 пакетов у них всех одинаковый.
у 40% блок тела состоит из выборки данных с различных регистров - это один пакет.
У остальных 40% блок тела состоит также из выборки с различных регистров - это один пакет + выборка с других реигстров - это второй пакет, и потом они соеденяются - это тртий пакет.
Потом идет блок подвала, где результат выборки тела соеденятсяе с результатом выборки с шапки.
Так вот структура одинаковая, но отборы дял регистров тела разные.
Планируется сделать так, чтобы дать юзверю самому для каждого регистра вводить отборы интерактивно.
Потом запрос должен будет сам программно собраться в оидное целое с теми отборами что юзверь задал и отработаться.
Такое реально реализовать через СКД?
Я вот думал что можно задать для каждого регистр свой СКД, потом эти СКД должны будут както соеденится и потом они должны будут соеденится с шапкой и с подвалом.
Но вот можно ли такое сделать программно?
Например создать программно СКД, тело будет как схемы объеденные, потом через связи наборов данных это все опять же программно должно будет склеиться. Такое реально? Есть у кого пример?

(0) можно.
можно тупо разные схемы сделать и собирать отчет из xml - типа загрузить настройки или получить схему

(0) Жуть какая. Три раза прочитал - ничего не понял. Давай то же самое, но в картинках.

(0) сферический расчет в вакууме делать только на абаке.
Без хоть минимальной конкретики не взлетает

Ну вот представьте 10000 Запров.

Структура запросов:
Шапка запроса
+
Тело запроса (отборы в ГДЕ и в Виртуальных параметрах)
+
Подвал запроса ("Шапка запроса" по определенным полям соеденяется левым соеденением с "Тело запроса")

Так понятней?

(4) шапку и подвал СКД сама рисует, отдельные запросы для этого не нужны

(5) врятли СКД читает мысли, там надо задавать что именно мне надо! я условно назвал запрос шапкой + Телом + подвалом, чтобы разделить логику

(0) Не надо пользователю лишние крутилки давать - 99% это только запутывает.

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

(4) ну и дальше что?

(8) дальше как я описал в (0) даем юзверю право делать отборы на тело в интерфейсе и потом все собираем хз каким-то чудо образом через скд в коде...
вы хотите помочь или просто спрашивайте чтобы сказать что это бред?

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

(9) Пользователю нужно готовое решение. Он не должен "греть голову" на тему где и что брать. Все должно быть просто и понятно, чтобы даже "лопата с глазами" могла разобраться.

А тут даже я не понимаю, что ты хочешь замутить.

(9) собирай таблицу и подсовывай ее как источник в СКД

(10)(12) есть пример как это программно реализуется, особенно момент с связями наборов данных?

(13) связи наборов данных можешь замутить на закладке СКД соответствующей

(14) Так у него для разных отчетов будут разные связи (если я правильно понял). И тут нужно программная организация "связи".

(15) ну хз, я понял так, что просто три набора различны :)

(15) Это не отчеты буду, а программные СКД, и связи буду разные лишь в нескольких видах запросах, т.к. для 50% будет один тип связи, для других 50% другой тип связи.

(17) а занафига тебе тогда именно СКД?

(18) Тогда расскажи как можно в моем случае сделать, коли не СКД?

(0) При такой постановке ответ один - не взлетит

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

(21) а хошь - регистры нарисуй грамотно, что бы одним запросом собирать :)

(21) (22) это все не то
еще раз конкретика: (0) + (4) + (9).
что именно неконкретного то?

а я бы сделал через вложенные схемы

(0) генеришь программно запрос, выкидываешь в ТЗ,
ПриКомпоновкеРезультата выкидываешь ТЗ в СКД, с указанием схемы, если их необходимо не 1

(23) Ты описываешь порядок разработки. А что хочешь в итоге получить? Универсальную "фишку", которая позволит генерировать любые отчеты с любым набором регистров? Я правильно понял?

(25) в ТЗ нельзя, т.к. строк бывает до миллиона.

(27) зачем и кому нужен отчет на 1 млн строк?

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

(24) а как ты будешь эти схемы соединять друг с другом?

(30) а как соединяются вложенные схемы? так и буду

(19) Есть еще ПостроительОтчета, ПостроительЗапроса.

(29) А может просто добавить нужные регистры?

(32) это не то
(33) поделись подробнее

(29) Не взлетит.

(34) Если приходится долго и упорно выбирать данные - может стоит завести регистры, где данные будут лежать в более удобном виде?

(36) там по сути они и лежат "В ТЕЛЕ" в удобном виде, какое хошь отборы такие и делай там

(35) откуда такая мысль?

(38) Из опыта.