Вопрос состоит в том, как используется уже существующее соединение. Процесс оптимального использования уже существующего открытого соединения я представляю приблизительно так (опять таки у меня нет исходников, не знаю как работает метод regData, если так как я напишу, то это просто супер):
1) Имеем какое либо открытое соединение (OleDB, SQL и т.п.);
2) В созданный объект класса Report добавляется ссылка (не копируется объект! и не создается свое исходя из параметров строки соединения уже имеющегося) на это соединение.
3) В режиме дизайнера используем это соединение для создания источника данных, который потом сохраняется в теле отчета со ссылкой на используемое соединение (идентифицируемое например по имени, наверное самое проблемное место, т.к. имена возможно могут быть одинаковые для нескольких используемых соединений, возможно использование доп. ID для идентификации, правда о соответствии должен будет забодиться уже программер, использующий компонент).
4) Формируем отчет с использованием источника/источников данных.
5) Сохраняем отчет.
6) В режиме просмотра при загрузке отчета проверяется наличие в поле(скорее всего типа коллекции) объекта класса Report ссылок на сохраненные в источниках данных соединения и их состояние коннекта. Если все OK, т.е. они найдены, открыты и т.п., получаем данные из них в источники данных и отображаем. Если нет...
Таким образом не приходится создавать новое соединение, используя параметры уже существующего, открывать его и т.д. Я понимяю, что это скорее всего просто вариант, который устроил бы возможно только меня, и в нем вероятно есть несколько узких мест :dreamer: . Но мечтать как говорится не вредно. Опять таки прошу снисхождения, не видел исходных кодов, т.к. перед покупкой компонента руководство требует его всестороннего изучения и исследования. А вообще мне и не только мне уже очень нравится. :biggrin:
Сохранение источника данных
Сохранение источника данных
а как же быть в данном случае с активной транзакцией ?? 
)
Что то где то слышал что собираются в дальнейшем сделать поддержку нескольких транзакций на одно подключение, но сейчас это не так.
Выходит либо транзакцию надо завершать (откатывать), либо передовать в отчет вместе с подключением.
В прочем и то и другое решается с помощью построения нужной логической схемы функционирования приложения, и я так думаю, что в общем то в момент построения отчета, активной транзакции не должно быть, но все же, мало ли кому какую модель приложения придет в голову построить)
Мне больше по душе передовать в отчет сформированый в программе датасет, по след причинам:
1. Данные для отчета берутся не только из рабочих каталогов, но из результатов выборок и фильтраций, работа с которыми реализована в приложении и не вижу смысла еще раз реализовывать формы запросов средствами Stimul'а.
2. Не надо передовать информацию о подключении в отчет. тем более действительно не известно как и что там делается с этим подключением.
) Что то где то слышал что собираются в дальнейшем сделать поддержку нескольких транзакций на одно подключение, но сейчас это не так.
Выходит либо транзакцию надо завершать (откатывать), либо передовать в отчет вместе с подключением.
В прочем и то и другое решается с помощью построения нужной логической схемы функционирования приложения, и я так думаю, что в общем то в момент построения отчета, активной транзакции не должно быть, но все же, мало ли кому какую модель приложения придет в голову построить
) Мне больше по душе передовать в отчет сформированый в программе датасет, по след причинам:
1. Данные для отчета берутся не только из рабочих каталогов, но из результатов выборок и фильтраций, работа с которыми реализована в приложении и не вижу смысла еще раз реализовывать формы запросов средствами Stimul'а.
2. Не надо передовать информацию о подключении в отчет. тем более действительно не известно как и что там делается с этим подключением.
Сохранение источника данных
Формировать датасет в приложении удобно, если есть небольшое кол-во отчетов. А если их больше 50, предпочтительным для меня является создание оного в дизайнере и хранение вместе с отчетом. Так лично для меня удобнее, да и приложение не усложняется. :biggrin: Вот такие вот причины.
Сохранение источника данных
У меня в приложении 48 таблиц, по которым строятся отчеты,
для большинства таблиц идет по несколько отчетов, причем для каждого из отчетов несколько форматов: книга, альбом, оптима. По сути данные одни и теже, только формат страниц отличается.
Вот столько отчетов в базовой версии получается, а там дальше, конечные пользователи, думаю еще понастряпают...)
Да и с датасетом пользователям будет проще отчеты делать.
Во первых: в датасете, указываю альясы для всех полей на русском языке (разумеется не ручками
Во вторых: отчет строится для определеных каталогов, и в источниках данных у нас только эти каталоги с необходимыми нам данными, а не список из всех таблиц базы и не обходимостью задания всяких условий при постороении отчета самим пользователем в процессе проектирования отчета...
В прочем цели и задачи разные и оптимальные решения тоже отличаются...
Есть небольшое неудобство, приходится дополнительно в БД сохранять информацию о том какие каталоги (Представления БД) участвуют в качестве исходных для отчета.
Vital> Можете уточнить, что подразумевается под сохранением источника данных?
Вот это и подразумеватеся под сохранением источника данных.
Даже если и возможно сохранение схемы датасета вместе с отчетом, все равно ее потом надо будет прочитать из отчета, и заполнить необходимыми данными.
для большинства таблиц идет по несколько отчетов, причем для каждого из отчетов несколько форматов: книга, альбом, оптима. По сути данные одни и теже, только формат страниц отличается.
Вот столько отчетов в базовой версии получается, а там дальше, конечные пользователи, думаю еще понастряпают...
)Да и с датасетом пользователям будет проще отчеты делать.
Во первых: в датасете, указываю альясы для всех полей на русском языке (разумеется не ручками
Во вторых: отчет строится для определеных каталогов, и в источниках данных у нас только эти каталоги с необходимыми нам данными, а не список из всех таблиц базы и не обходимостью задания всяких условий при постороении отчета самим пользователем в процессе проектирования отчета...
В прочем цели и задачи разные и оптимальные решения тоже отличаются...
Есть небольшое неудобство, приходится дополнительно в БД сохранять информацию о том какие каталоги (Представления БД) участвуют в качестве исходных для отчета.
Vital> Можете уточнить, что подразумевается под сохранением источника данных?
Вот это и подразумеватеся под сохранением источника данных.
Даже если и возможно сохранение схемы датасета вместе с отчетом, все равно ее потом надо будет прочитать из отчета, и заполнить необходимыми данными.
Сохранение источника данных
Про цели, средства, да и про предпочтения это верно. хотелось бы услышать разработчиков.
Сохранение источника данных
Так и есть. В DataStore сохраняется только ссылка.BeraleX писал(а):Вопрос состоит в том, как используется уже существующее соединение. Процесс оптимального использования уже существующего открытого соединения я представляю приблизительно так (опять таки у меня нет исходников, не знаю как работает метод regData, если так как я напишу, то это просто супер):
1) Имеем какое либо открытое соединение (OleDB, SQL и т.п.);
2) В созданный объект класса Report добавляется ссылка (не копируется объект! и не создается свое исходя из параметров строки соединения уже имеющегося) на это соединение.
3) В режиме дизайнера используем это соединение для создания источника данных, который потом сохраняется в теле отчета со ссылкой на используемое соединение (идентифицируемое например по имени, наверное самое проблемное место, т.к. имена возможно могут быть одинаковые для нескольких используемых соединений, возможно использование доп. ID для идентификации, правда о соответствии должен будет забодиться уже программер, использующий компонент).
Так и есть. Перед построением отчета идет соединение каждого источника данных с данными по имени DataName. Т.е. в данном конкретном случае происходит поиск OleDbConnection с конкретным именем. Если найдено - используя это соединение данные считываются, если нет - источник данных даные не считывает. Но вот добавлять соединение в DataStore необходимо уже разработчику т.к. это внешние данные, их нельзя сериализовать вместе с отчетом.4) Формируем отчет с использованием источника/источников данных.
5) Сохраняем отчет.
6) В режиме просмотра при загрузке отчета проверяется наличие в поле(скорее всего типа коллекции) объекта класса Report ссылок на сохраненные в источниках данных соединения и их состояние коннекта. Если все OK, т.е. они найдены, открыты и т.п., получаем данные из них в источники данных и отображаем. Если нет...
Таким образом не приходится создавать новое соединение, используя параметры уже существующего, открывать его и т.д. Я понимяю, что это скорее всего просто вариант, который устроил бы возможно только меня, и в нем вероятно есть несколько узких мест :dreamer: . Но мечтать как говорится не вредно. Опять таки прошу снисхождения, не видел исходных кодов, т.к. перед покупкой компонента руководство требует его всестороннего изучения и исследования. А вообще мне и не только мне уже очень нравится. :biggrin:
Сохранение источника данных
Можно удалять автоматически из отчета все неиспользуемые источники данных и колонки перед его сохранением. Перед вызовом дизайнера обратно добавлять все, что необходимо для построения отчета:Xptr писал(а):У меня в приложении 48 таблиц, по которым строятся отчеты,
для большинства таблиц идет по несколько отчетов, причем для каждого из отчетов несколько форматов: книга, альбом, оптима. По сути данные одни и теже, только формат страниц отличается.
Вот столько отчетов в базовой версии получается, а там дальше, конечные пользователи, думаю еще понастряпают...
Да и с датасетом пользователям будет проще отчеты делать.
Во первых: в датасете, указываю альясы для всех полей на русском языке (разумеется не ручками
Во вторых: отчет строится для определеных каталогов, и в источниках данных у нас только эти каталоги с необходимыми нам данными, а не список из всех таблиц базы и не обходимостью задания всяких условий при постороении отчета самим пользователем в процессе проектирования отчета...
В прочем цели и задачи разные и оптимальные решения тоже отличаются...
Есть небольшое неудобство, приходится дополнительно в БД сохранять информацию о том какие каталоги (Представления БД) участвуют в качестве исходных для отчета.
Для удаления: report.Dictionary.RemoveUnusedData();
Да добавления: report.Synchronize();
Vital> Можете уточнить, что подразумевается под сохранением источника данных?
Вот это и подразумеватеся под сохранением источника данных.
Даже если и возможно сохранение схемы датасета вместе с отчетом, все равно ее потом надо будет прочитать из отчета, и заполнить необходимыми данными.
Сохранение источника данных
Как для меня. так лучше и не придумаешь! :biggrin: