Dimitry SibiryakovV.BorzovГружу отчет, пока отчет грузится, приложение адекватно реагирует на запросы пользователя,
вплоть до того, что можно еще пару отчетов открыть и загрузить.

Для создания таких приложений следует забыть про DB-aware, которое рассчитано
исключительно на мышекликанье поделок класса фишфак и начать-таки программировать. Для
начала можешь посмотреть на MVC паттерн (в котором из хороших идей только инкапсуляция
отображения данных и отрыв его от процесса получения данных, но и то уже хлеб).

Чего-то я Вас не пойму. В чем проблема-то? Открываем отдельный коннект, загружаем данные, передаем форме. Ньюансы лишь в том, в какой форме передаем данные. Почему бы приложению не открыть параллельно еще пару отчетов и не включить на их выполнение? FibPlus позволяет, не так?

kdvV.Borzovплоть до того, что можно еще пару отчетов открыть и загрузить.
где ты такую хрень видел? Это только в трехзвенном сервере отчетов отчеты параллельно выполняются, сохраняются, и выдаются пользователю потом, по запросу.
В общем - для briefcase надо использовать TClientDataSet. Параллельно запросы работают только в разных коннектах к БД.
Раз надо несколько коннектов - значит надо.
Коннект с активной транзакцией read read_committed никак не нагружает сервер.
В общем, фигней вы занимаетесь, гражданин. Что с потоками, что с CachedUpdates. Нельзя вот так взять, и сразу собрать трактор, если не знать как устроен двигатель, и прочее.
Я и сказал про отдельный коннект к БД. И больше проблем не вижу. Вопрос только в том, держать ли этот коннект и дальше, если возвращаемый датасет является TpFibDataset, пока юзер форму не закроет (я так и делаю), или можно всё закрыть, оставив его открытым с помощью CachedUpdates. С TClientDataset всё проще, но затраты на перекачивание данных в него бывают иногда достаточно большими, и лучше уж прямо TpFibDataset передать.
Писали тут на форуме, что можно и одним коннектом в FibPlus даже обойтись. Я тестировал, вроде и правда всё работает, но на практике клиенты пока это не гоняют.

Вопрос мой про длинную активную транзакцию никак не пересекается с этим вопросом, не пугайтесь Вы :) Просто в топике зашел разговор о cachedupdates, а я еще попытался избавиться с помощью этого CachedUpdates и от самого отдельного коннекта в отдельном потоке, это третья тема :) Но поднял их тут не я.

Dimitry SibiryakovV.BorzovВ чем проблема-то? Открываем отдельный коннект, загружаем данные, передаем форме.

Практически во всём. Начиная с того, что уже тут мы откладываем "передачу данных" на конец
загрузки. А всё это время пользователь наблюдает пустую форму. И да, параллельно можно ещё
пар отчётов запустить, вот только, насколько я помню, FastReport так и не научился строить
их в фоне, он "унутре" мается всякой фигнёй, начиная с Application.PrecessMessages.


Любой отчет чтобы получить, нужно дождаться окончания его расчета. А как иначе? Или я Вас не понял. Поэтому в любом случае юзер сидит и смотрит на пустую форму. Неужели Вы считаете, что Application.ProcessMessages - это достойная замена выполнению в отдельном потоке? А насчет маяться фигней - ну, частенько клиенты открывают другой экземпляр приложения, чтобы, пока "грузится отчет", что-то другое поделать. Так что почему бы не дать им возможность делать это прямо в этом же экземпляре приложения?

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

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

А чем это лучше пяти открытых приложений с теми же формами? Да и потом, это одна из задач, а другая - сделать приложение адекватно реагирующим на команды пользователя.

чем это хуже, хотел я сказать.

Старый плюшевый мишкаV.Borzovчем это хуже, хотел я сказать.

Ориентироваться в 5 SDI через альт-таб или трей, понимая куда и зачем идёшь, пользователю гораздо проще, чем в разлапистом MDI с непрогнозируемыми перекрытиями. Мне так кажется. И программисту тоже жить проще - пространство для всяких коллизий сужено.
Я тут с Вами поспорю:
Во-первых, надо давать пользователю возможность работы как в MDI, так в SDI.
Во-вторых, пусть пользователь сам решает, удобнее ли ему открыть пять раз одно приложение, или открыть в одном приложении пять отчетов. И тут в полный рост может встать проблема использования локальных ресурсов приложения, таких как инишки, например. Ибо пять приложений будут работать с одним и тем же ini-файлом. Это к примеру. То есть, к базе получаем комфортный для программиста доступ, но задаем ему задачки разделения между приложениями локальных ресурсов.
В-третьих, вопрос возможности выполнения запросов в отдельном потоке нужен далеко не только для того, чтобы юзер мог открыть одновременно 5 форм, а, еще раз говорю, для адекватной реакции приложения на юзерские команды.

kdv,

Возможность запуска нескольких отчетов всплыла как приятный бонус, это не было целью. Главная задача - дать приложению возможность адекватно реагировать на юзерские действия. Однако, если такая возможность есть, то уж лучше пусть это делается в одном приложении. Это - на мой взгляд, и не вижу тут предмета спора, чистая вкусовщина. Даем возможность юзеру, а он пусть сам решает. Тем более, что с вопросами запуска нескольких приложений могут возникнуть другие проблемы (работа с локальными данными, не рассчитанными на мультиюзерскую работу, tinifile, например).
А возможность такую дают, как ВЫ заметили, и сам Firebird, и, вроде как теоретически и FibPlus (подключение нескольких потоков через один TpFibDatabase), и тогда это вообще один коннект.

Dimitry SibiryakovФетчить записи в потоке это хорошо, но с наследниками TDataSet не работает.

Почему не работает? Что случилось с TDataset?

Dimitry SibiryakovV.BorzovГлавная задача - дать приложению возможность адекватно реагировать на юзерские действия.

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

Открывать запросы в потоке это хорошо, но при этом следует запросы писать так, чтобы
открытие и получение первой записи было быстрее реакции пользователя. А для этого надо
особым образом проектировать БД.

Фетчить записи в потоке это хорошо, но с наследниками TDataSet не работает.

Строить отчёты в потоке это хорошо, но см. предыдущие два пункта.


Открываю форму, запускаю запрос, пока он идет открываю такую же, запускаю запрос, ещё и еще, все 8 ядер нагружены по самое не хочу, полет нормальный. Сообщить потоку о своем желании его остановить могу в любой момент, а сам поток отзовется между фетчами. Проблем нет. Не знаю, что у Вас там не работает.

kdvV.Borzovвсе 8 ядер нагружены по самое не хочу, полет нормальный
эээ. чем они нагружены? фетчем данных с сервера, что-ль?
Вот сейчас запустил 5 одинаковых отчетов, на 8 ядрах сам файерберд-процесс (третий суперсервер) - 60% процессорного времени, приложение - 6%.

По CachedUpdates (ну, или poDontCloseAfterEndTransaction), я писал про полученные ошибки жуткие, такая история получилась:

Удалять транзакцию или удалять датабейз после открытия данных, ни в коем случае нельзя, конечно, но деактивировать транзакцию и сам коннект - можно. Только вылез ньюанс, который не заметен, если транзакцию закрываем, а коннект оставляем открытым, но приводит к ошибке "database is not open", если не просто закрыть транзакцию, но и отконнектиться. Выглядит так: открываем данные выводим в грид, делаем дисконнект, вроде всё отфетчено, как и положено, но те поля TFibStringField и TFibWideStringField, и которые оказались в отображенном гриде правее области отрисовки, они оказались не препарированными ( FPrepared = false у них), и когда при прокрутке на них происходит попытка их отрисовки в гриде, поля требуют коннекта. То есть, вроде бы отконнектились, а в буфер-то данные не прочитали.

Вот такой костыль: for i := 0 to fieldcount-1 do fields[i].asvariant , выполненный перед закрытием коннекта, устраняет ошибку. Я же прямо в TFIBCustomDataSet.DoDatabaseDisconnecting и TFIBCustomDataSet.DoTransactionEnding воткнул сразу после FetchAll вот это:




Не знаю, работает пока :)

kdvV.Borzov и тогда это вообще один коннект.
в одном коннекте параллельные операции невозможны.
Да, согласен. Направил все потоки на один FibDatabase, вышло забавно: он всё отрулил, не упал, данные выдал корректные. Но отсемафорил, естественно, всё в одном своем потоке. запусти хоть 5 хоть 10 потоков, без разницы. Такая схема работы, конечно, на фиг не нужна, разве что только в качестве аварийного случая. А так- если уже подключаться, то каждый раз отдельным коннектом. Однако это всё равно с точки зрения интерфейса всё выглядело лучше, чем Application.processMessages :)

kdvV.Borzov,

что-то мне эти откровения про FIBplus кажутся бессмысленными. Эксперимент ради эксперимента?

Вы про один коннект на все потоки? Ну, когда пройден путь с разными коннектами, почему не проверить, как это работает с одним коннектом, раз умные люди пишут, что fibPlus настолько ThreadSafe. И еще был когда-то давным-давно затык с какими-то там версиями виндов, когда количество подключений к серверу базы оказалось ограничено.... Может, этого нет уже ничего, но почему бы не перебдеть (а то наплодим коннектов), если это почти ничего не стоит по затратам :) А вот отчеты в отдельных потоках с отдельными коннектами - это обязательно. Стараюсь во всех отчетах этого придерживаться сейчас. Кроме, конечно, отображения справочников, там тупо открываем первые строчки, в потоке приложения, а потом дофетчиваем по 21 строке по Application.idle.