Приветствую. Для поддержки одного старого софта возникла необходимость доработки.
Используется FastReport 4 и Delphi 2007.
Имеется 2 потока, в каждом из которых открыт ADOConnection к MsSQL серверу.
ADOConnection создается внутри потоков и явно работает корректно при всех обращениях к БД.
Также имеется TDataModule в котором находятся TfrxReport, TfrxADOComponents, TfrxPDFExport
Каждый из потоков создает отдельный экземпляр этого TDataModule, передает туда свой ADOConnection, который устанавливается в DefaultDatabase у TfrxADOComponents компонента.
Каждый из потоков создает временные таблицы, запускает несколько StoredProcedures для из заполнения (естественно входные параметры разные), после этого через TCriticalSection только 1 из потоков юзает свой экземпляр DataModule c FastReport компонентами, выгружает полученные отчеты в PDF.
Но получается, что всегда! используется ADOConnection, который был задан последним!!
Естественно вот это:


проставлено.
Я проверял и через Profiler, и через тупой вывод SPID в отчет. FastReport работает только со вторым ADOConnection.
Как от этого избавиться? Перейти на 6й репорт и проверить там, к сожалению, нет возможности.

Код могу дать, но он еще сильно в разработке, так что недоделаный до конца. Я, вообще уже 4 года на C# сижу, понадобилось вот дописка в старый проект.
В по поводу "хрени", которая не работает, можно подробнее. Я вообще не работал с FastReport в многопоточности.


Тут 2 причины:
1. Если очень большой объем данных (ну там на 25000 страниц в PDF), то случались вылеты по Out Of Memory (32 бита...)
2. Я исходно предполагал, что FastReport не будет корректно работать с одновременной генерацией из нескольких потоков. Но не до такой степени.
На самом деле вся эта тема именно для того, чтобы генерить большие объемы, в несколько десятков тысяч страниц. Просто объем делится на куски по отдельному принципу, а потом генерится кусками.


К сожалению не могу.
Ибо сам отчет должен иметь в себе заранее мне неизвестное количество TfrxADOTable, TfrxADOQuery и прочего.
Т.е. получается как:
Вызывается процедура, которая возвращает текст запроса на создание/удаление темповых таблиц, он вызывается в каждом из Connection-ов. Потом вызываются процедуры, которые заполняют это дело.
А потом по этим темповым таблицам строятся отчеты.
Сам отчет берётся тоже из БД.
А таких БД в дальнейшем будет... много. Не спрашивайте почему, просто так было сделано много лет назад. Когда я еще в этой организации и не работал. Мне тоже не очень нравится подход, но его невозможно изменить полностью не переписав всю приложуху.

wadman,
Кстати да, точно. Попробую так.
Забыл я о таком методе.
ъъъъъ,
К сожалению не реально, т.к. это будет dll, аля плагин.
Иначе, если бы это было stand alone, я б писал на C#

Итого отвечу сам себе.
Я победил формирование отчетов в FR4 из нескольких ADOConnection.
Могу выразить ОГРОМНОЕ ФИ разработчикам FR4. Как в FR6 не в курсе, не изучал.
Вчера потратил некоторое время на изучение исходников FR4 и понял одну деталь. Компонент TfrxADOComponents должен быть 1 на ПРИЛОЖЕНИЕ. Он сохраняется внутри FR без привязки к классам. Бред да и только.
Итого. В моём приложении есть ещё один глобальный TDataModule, к которому есть доступ отовсюду. Такой Singleton без красивостей...
В общем, положил я туда единственный экземпляр TfrxADOComponents, и перед генерацией отчета кидаю в него тот ADOConnection, по которому должны строиться отчёты. Очень сильно пригодилось мне то, что я исходно генерацию сделал через Critical Section, чтобы была только 1 генерация в одно время.
Работает. И вроде как, стабильно. Сейчас крутится тестовый прогон на 300 000 страниц. Уже к концу подходит. Конечно в реальности 300 000 вряд-ли будет, но лучше уж оттестировать нормально, особенно пока дома сижу на удалёнке, т.к. дома комп в разы мощнее, чем на работе.

ъъъъъ,
Разбрасывается генерация ДАННЫХ из MSSQL, т.к. она занимает тоже приличное время.
А генерация отчетов делается по очереди.
И получается, что 1 поток генерит отчеты, 2й генерит данные, потом они меняются, и так до победного.

ъъъъъ,
Уходим в лирику, но поясню.
Есть старый алгоритм, написанный когда я ещё о существовании организации, где он используется не знал, но работающий на 200+ базах данных (о том, что баз 200+ и что это плохо, а что это плохо, я согласен на 146%, тема отдельной дискуссии, но без тотальной переделки структуры БД по другому не сделать).
В каждой из этих БД структура данных подобна, но разная. Вкратце работа происходит по следующему алгоритму:
1. Из БД берется информация о структуре данных (темповые таблицы, их может быть разное количество и разные сами таблицы от БД к БД).
2. В соединении они создаются.
3. Запускается ряд процедур, которые генерят данные в эти темповые таблицы (вот этот кусок и распараллелен)
4. Из БД же загружается отчёт.
5. Он строится из данных, созданных в п.2 и п.3 и выгружается в PDF.

Моё приложение ВООБЩЕ ничего не передает в отчёт. Оно вызывает процедуры для создания данных и запускает построение отчета/выгрузку в PDF.

Принцип распараллеливания следующий. Есть ещё одна темповая таблица, хоть она одинакова, в ней лежат ID объектов по которым надо построить данные/отчёты. Соответственно раньше в неё забрасывались ID всех объектов, по которым надо всё сгенерить, сейчас же есть самописный потокозащищенный TList c этими ID, и они постепенно забираются из него и по кускам строятся/выгружаются.

DimaBr,
Всё уже сделано. Вопрос был как заставить FastReport обрабатывать данные от нескольких ADOConnection и он решён. Надо было без изменений самих отчётов.
Всё работает.

wadman,
Код, да пожалуйста:



При условии, что я ничего не указал в Value, а именно так и происходит, берется ADOComponents.DefaultDatabase.
Он в свою очередь объявлен как:


в интерфейсной части модуля frxADOComponents.

И то, что TfrxADOComponents положенный вообще в отдельный DataModule, а перед генерацией очередной части отчетов, я меняю DefaultDatabase у него, и при этом всё работает, подтверждает мою догадку, что берется именно этот, определенный вне классов, экземпляр TfrxADOComponents.
Это актуально для FR 4.15, как в 6-ке я не могу сказать.