Ветвление в связанных отчетах, как правильно?

Александр

Здравствуйте!

Не подскажите как правильно выстроить цепочку отчетов

Есть объекты Obj1, Obj2, Obj3, Obj4 нужно получить отчет собрав нужную информацию из всех объектов
мои действия

Отчет1 получает из Obj1 адреса Obj2, Obj3, Obj4

Отчет2 получает на входе адрес Obj2 (из первого отчета) берет нужную информацию и передает ее и адреса Obj1, Obj3, Obj4 из первого отчета (через свои вычисляемые поля) дальше

Oтчет3 получает на входе адрес Obj3 (из второго отчета) берет нужную информацию и передает ее и адреса Obj1, Obj4 из второго отчета (через свои вычисляемые поля) дальше

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

Отчет5 получает на входе адрес Obj1 (из четвертого отчета) и всю ранее собранную отчетами информацию добавляет к ней даные по своим дочерним объектам (таблица) и заканчивает работу

Комментарий: Отчет стартует с Obj1 и заканчивает на Obj1 в связи с тем что на форме отчета сначала необходимо заполнить шапку а потом добавить таблицу значений своих дочерних объектов

Подскажите
1- Нельзя ли в аргументах отчетов 2-5 использовать разные источники данных, чтобы не тащить все поля из отчета в отчет, а использовать во всех связанных отчетах аргументы первого отчета + свои собственные по мере прохождения
2- Как обойти тот факт что выделенный объект может не существовать (Отчет 4), а информацию нужно передать дальше? В голову приходит только одно - зная признак (обрабатывать Obj4 или нет) вызывать разные цепочки если да то запускать цепочку всех отчетов если нет то все за исключением 4го. Может есть способ изящнее?

Anderyt · Сообщение **Anderyt** » 28 сен 2006, 12:00

выходит, есть несколько пар отчетов с источниками данных???
а это все выполняется для одного объекта или для нескольких? интересно, как долго выполняется вся это цепочка?
а вообще, стало любопытно, какая прикладная задача решена таким образом. просто первое впечатление - а не слишком ли сложно?

заранее сорри, что это не ответ на вопрос, а еще один вопрос...

Александр

Андрей привет! Все это ты мог видеть на прошедшей конференции 22.09.06 в нашей настройке для женщин

Ответ простой
Есть дерево

Код: Выделить всё


1. Клиент 1
    1.2 Сделки
         1.2.2 Сделка 1
            1.2.2.1 Товар 1
            1.2.2.2 Товар 2
                  ...
            1.2.2.n Товар n
 
    1.3. Контактные лица
         1.3.1 Контактное лицо 1
         1.3.2 Контактное лицо 2

2. Клиент 2
...
   2.3 Контактные лица
         2.3.1 Контактное лицо 1
...

Задача - получить отчет по сделке 1

Сделка 1:
- знает адрес владельца (Клиент 1)
- знает адрес контактного лица владельца (Клиент1/Контактные лица/Контактное лицо1)
- знает адрес грузополучателя (Клиент2)
- знает адрес контактного лица грузополучателя (Клиент2/Контактные лица/Контактное лицо1)
- имеет дочерние объекты Товар

Зная всю исходную информацию мне нужно пробежаться по адресам, взять недостающие поля и сформировать полный отчет

Цепочка выполняется быстро т.к. я использую только выделенные объекты (1й уровень)

Заранее отвечаю на следующий вопрос
У нас каждый объект тяней за собой хвост ID объектов с которыми он вступал в отношения, поэтому мы можем работать 'вслепую' и строить сложные отчеты. Но были вынуждены отказаться от drag & drop и полностью (Устно

) запретить пользователям использование кнопки 'Del'+некоторые пункты контекстного меню в деревьях

Александр

Экспериментальным путем удалось выяснить, что
если в 10 связанных отчетах - 5му в качестве выделенного объекта (на вход) пришел несуществующий ID (0 или NULL) и при этом 5 отчет передает сквозные атрибуты через свои вычисляемые поля дальше (от первого+2+3+4) - Лоция не умирает и продолжает формировать цепочку отчетов пока не сделает последний!!!

Остался только один вопрос Как сделать так чтобы не тащить все сквозные атрибуты от начала до конца, а в очередном отчете каждый атрибут настраивать на свой источник возникновения???

Anderyt · Сообщение **Anderyt** » 28 сен 2006, 14:02

настройку с mega-user-friendly интерфейсом я помню, но вот отчета - что то нет...

на неск. раз уже перечитал задачу и имеющееся решение, но все равно не могу ничего понять

столько отчетов с источниками, ужас... а вот этот самый хвост ИД объектов - это в каком виде? в одном атрибуте? или в неск-х, для каждого типа "знакомого" объекта - свой?
или у каждого след-го объекта есть "ссылка" на один объект дальше по цепочке? мне когда шеф сказал, что в вашей настройке объекты связаны по ИД, я не понял, а почему не по связям? почему отказались от использования связей? если бы объект Сделка был связан с объектами Владелец, Контактное лицо владельца, Грузополучатель и Контактное лицо грузополучателя, то вроде в одном отчете можно было бы получить атрибуты по всем этим связям... или нельзя?

Александр

да отчет пишу только сейчас, уже описал 8 уровней

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

1й момент
Так вот каждый тип объекта имеет достаточное число (фиксированное) числовых атрибутов которые зарезервированы под все все возможные вхождения объекта, например
Клиент
-адрес первичной входимости объекта в базу где был создан
-адреса всех дочерних папок (5 уровней) (для ускорения поиска)
-адрес возможной входимости объекта (в соответствии с текущими настройками атрибутов) и т.д.
Объект сделка уже смотрели
Объект Участник семинара (производный объект созданный на основе контактного лица)
-адрес входимости в семинар
-адрес прототипа
-адрес организации прототипа
-адрес сделанного запроса (если был)
.....

2й Момент
-все объекты всегда существуют только в единственном числе но могут входить в разные деревья эта информация хранится в адресных атрибутах и (если нужно) в виде строки объекта где указано например что с данным клиентом работают 10 менеджеров - имя статус через; При смене состава/статуса строка все время обновляется и адреса если нужно

3й Момент
-основываясь на предыдушей информации не открывая дерева проекта (есть достаточно большие до 8000 объектов) я могу работая с одним объектом (без всего дерева) прочитав какой либо статус понять либо по адресным атрибутам либо из символьной строки - где он находится сейчас, куда входит - перейти из него на любой объект (указанный в атрибутах адреса)+ произвести перепривязки объекта 'сразу' в нескольких деревьях (в ФОНЕ) и самое главное выполнить отчет из единственного открытого объекта получив любую информацию на любом уровне вложенности пробежавшись по адресам родственных объектов

и последнее - проблема в том - что я не понял для чего нужны горизонтальные связи, а работа зашла уже слишком далеко и все вроде нормально. Как разберусь обязательно применю. Выжмем из Лоции все.

Просто с базами работаю первый раз и с позиции объектного программирования моя модель вроде укладывается в схему

)

Александр

Наверно можно и по горизонтальным связям, ведь все объекты куда то завязаны (в воздухе никто не висит, пресекается на корню

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

Ведь весь это огород пришлось городить из за двух убогих функций LinkGetParent и LinkGetChild работающих только в открытых деревьях.

Anderyt · Сообщение **Anderyt** » 28 сен 2006, 15:05

да, с точки зрения этой модели - все выглядит отлично! объект хранит в себе те атрибуты, которые свойственны только ему...
а как происходит переход от объекта к объекту? запускаем действие, выбираем определенный тип ИД объекта, вытаскиваем его у текущего объекта, потом находим объект с таким ИД и открываем его?
повторюсь, с точки зрения модели и самой структуры данных все продумано великолепно. однако мне кажется, что отчеты в Лоция ПДМ было бы проще сделать для связанных объектов, чем вытаскивать объекты по атрибутам с ИД, перебирая всю цепочку объектов.
в той настройке, которую я показывал на конференции, как раз используются связи и как раз при построении отчетов. там тоже есть свои ограничения, но у меня получилось их обойти. ну это так, ерунда, у нас связи жутко используются в договорном направлении, это ужас... договор связан с этапами, контрагентами, еще с кем то... или вы пробовали отчеты по связанным объектам и не понравилось?

Александр

Переход происходит просто по ссылкам. Атрибутивная форма несет на себе несколько кнопок с описанием (например Название семинара, Или Наименование клиента) которые завязаны на конкретный атрибут (ID объекта) - запускаем действие, переходим,

Код: Выделить всё

ID = AttribGetDefault ( a_Object , LinkID_0 , ID_Client например,0 )
...
TempObj=SetByID(ID) //объект без типа (типа Variant)
WndTree(TempObj)

или если есть несколько точек выхода из объекта - предлагаем юзеру выбрать куда пойти сейчас.

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

руководству, хотя народ вроде работает и без этого) Для нас на текущий момент важна только -=СКОРОСТЬ- внесения и поиска информации. А бюрократизировать мы это будем позже.

Старик Крупский

Прочитал всю цепочку переписки аж два раза. Потом поужинал. Потом решил, что читать надо только первый топик. Потом посмотрел модель данных, нарисовал конкретные данные в Excel

Да, аргументы нужно тянуть через все отчеты, накапливая их. Или догонять их SQL-запросом. В последних версиях это, наконец, можно делать.
Но суть не в этом. Александр, а не получится ли запустить отчет действием, этим же действием найти по айдишникам все нужные объекты, понадергать оттуда информацию, а потом все это отдать в отчет в виде аргументов. Может статься, что вообще один отчет получится, а

Александр

Зачет

Крупский - Вы гений

это факт!

Александр

Для Андрея (не личное (может и другим интересно))

Подумал на счет горизонтальных связей (пока еще не понял куда их воткнуть) но дело не в этом, а в том что объект Сделка никак не связан с объектом Грузополучатель. Ни по каким связям на него выйти нельзя, только косвенно, через поиск.
А так - Связи нет - а Отчет есть. Мы не заводим ненужные связи - Предохраняемся

Anderyt · Сообщение **Anderyt** » 29 сен 2006, 07:47

кстати да, предложение Крупского - это вещь

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

Код: Выделить всё

ID = AttribGetDefault ( a_Object , LinkID_0 , ID_Client,0 ) 
TempObj=SetByID(ID)

будет работать быстрее, чем поиск объекта...
так что в смысле перехода на объект по "связи" в действии ваше решение выглядит более привлекательным

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

да и кто мешает связать Сделку с Грузополучателем?

Александр

Убедил - почитаю по связанные объекты, тем более если там есть какой-то функционал.
Просто сейчас вроде логично при создании объекта Сделка и наделении его свойствами сразу воткнуть туда все адреса, тем самым не привязываться к функционалу Лоции, оставляя себе возможность поработать с базой напрямую. (Повторюсь - я мало чего понимаю в базах - и программировании, но придерживаюсь того, чтобы в любой момент максимально быстро и безболезненно развить/изменить/переделать/дополнить структуру данных и не вспоминать кто и с кем повязан.) Связи-да, визуально и понятно и все ок -но это все для пользователей, а для себя? нужно что-то больше...

Anderyt · Сообщение **Anderyt** » 29 сен 2006, 09:22

ооо!!! если очень охота работать напрямую с базой - то есть способ!

если связать два объекта связью с ИД = <ИД связи>, сделать действие с таким кодом:

Код: Выделить всё

Var_temp_str = Set ( f_ExecSQLSelect_2( 'select link_id from lsdbo.tree_link_view where parent_id = '+a_object+' and link_type_id = <ИД связи>', '','/') )
Obj_object = SetByID ( number(var_temp_str) )
WndTree ( Obj_object , a_LinkType )

и выполнить его на том объекте, К КОТОРОМУ мы добавляли другой объект (даже если связь равнозначная, все равно есть объект, ОТ КОТОРОГО исходит эта связь... это на уровне таблиц БД уже...), то ОЧЕНЬ быстро откроется связанный объект!
причем реально, ОЧЕНЬ быстро.
пробовал сделать то же самое на

Код: Выделить всё

Var_temp_str = AttribGet ( a_Object , LinkID_0 , attr_number )
Obj_object = SetByID ( number(var_temp_str) )
WndTree ( Obj_object , a_LinkType )

получается примерно так же