Здравствуйте, mrhru, Вы писали:

M>Может всё таки так:
M>Источник(и) данных -> XML -> ReportEngine ?

Я что-то никак не воткну, какой выигрыш дает XML. Его все-равно в DOM загнать целиком надо перед растеризацией.

M>1) XML — это стандартный универсальный способ. Любой другой способ создания/хранения/передачи деревянных данных будет просто повторять возможности XML.
Ну да, берем приличное количество бинарных данных, переводим их в XML, а затем engine генератора отчетов опять это в бинарный вид DOM переводит, путем распарсивания XML. Что, скоро пентиум 10Гц выходит? Можно тяп-ляп приложения писать?


M>2) Источники данных инкапсулируют в себе правила преобразования данных в деревянную структуру и могут быть созданы независимо — OLAP->XML, DataSet->XML, Array->XML, XML->XML ( )
XML — повторю для особо упорствующих. XML-это не конечные данные, это даже не исходные данные для растеризатора отчета. Это исходные данные для XML-parser-а.

M>3) Частный случай источника данных — это его "отсутствие" , т.е. все данные генерируются клиентской программой.
Ради бога. Сгенери структуру в памяти, и подай как источник данных для отчета! Об этом я и говорю.

V>>Пусть каждая строка данных отчеат содержит от 0-ля до бесконечности ПОДЧИНЕННЫХ НАБОРОВ ДАННЫХ (так сделано в одном из мощнейших генераторов Oracle Report Server).
V>>CristalReport, или Access например, предполагают, что если и может быть подчиненный набор данных, то только один. А это крайне порою неудобно.

M> Только, имхо, не каждая строка, а только специально заданные в шаблоне.
Это стеб, или в следующий раз надо жевать до самого дна? Мы обсуждаем возможности, вот я и говорю, путь каждая строка содержит от 0-ля до бесконечности подчиненных наборов данных. Количество этих наборов в каждом конкретном случае, разумеется (!!!), задается при проектировании шаблона конкретного отчета. Но ОЧЕНЬ желательно иметь такую возможность, т.к. генераторы отчетов, типа MS Access ПРИНЦИПИАЛЬНО не позволяют проектировать многие полезные разновидности представления информации.