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

Когда юзер захочет что-то найти поиском по таблице, или просто пролистав, то упрется в fetch с базы. К тому же, если он дойдет-таки до конца, то получит тот же самый Out of memory, а о выводе данных в отдельном потоке и говорить не приходится.

Благодарю за урок, но сейчас у меня стоит вопрос, как то, что уже давно работает, перетащить на новую технологию с минимальными, насколько возможно. затратами. Потом, возможно, буду ломать всё и рисовать новые прогрессивные отчеты в фастрепорте, в treeview или прямо в экселе. Но я и так уже слишком много переломал, настолько, что для того, чтобы перейти с BDE Paradox на Firebird, мне нужно переписать всю программу с нуля. С таким же успехом я мог её переписать на C++, немного бы потерял с точки зрения потраченного времени. Сижу вот и думаю, а мог ли я, почти ничего не меняя, перейти сначала на firebird из-под BDE, а потом уже дальше пойти? Не знаю.

В старом BDE приложении сидит и тупо смотрит на приложение, которой в одном потоке и рисует и считает. Разве что только еще одно приложение открыть, рискуя, что BDE подвиснет. В новом приложении уже шаг вперед: расчет выводится в отдельном потоке, и в той форме. Юзер же может так же тупо смотреть, а может еще что-то открыть в приложении. При таком подходе лучше сразу уже всё с сервера забрать, разместить в форме, и пусть себе дальше работает с этой формой, если она ему так нужна. Если не нужна, повторяюсь, то есть другие отчеты, всякие там сводные, где он увидит просто сумму, без детализации. Но раз ему тут надо, то пусть тут сидит. Выводить первые N строк, а потом заставлять фетчить при попытке юзера поискать что-то - это тот же самый старый подход: и счет, и отображение - в одном потоке. И скорость - одно дело я этот 6-гигабайтный DBF испоьзую, где все поиски и вся беготня практически мгновенно (я писал выше - while not eof do next за 5 секунд), а совсем другое дело, когда я юзеру показал N строк быстренько, а когда он сказал: "а найди-ка мне позицию с текстом "АБС", и приложение замерло, а, не на подходе к последним строкам еще и умерло.

Ну, изначально я и поинтересовался: 1) есть ли в FibPlus штатное средство для скидывания кэша на диск и работы с ним потом, не загружая это всё в оперативку, чтобы велосипед не изобретать. Ибо велосипед это 2) какие существуют удобные для этого датасеты. Например BDE-шные DBF и DB упрутся в 2 гига в лучшем случае, там всё. взял TDBF, он сохранил при tablelevel=5. Но у него других ограничений куча. Может, еще что-то есть для применения, чтобы избежать изобретения очередного велосипеда?

Ну, в FibDataset этот набор данных занял 1.2 гига в памяти, а выкачивал в память целиком 3 минуты, а в на диске - 900 мб, куда он сбрасывал секунды 4, не больше. Это DBF развернул его в 6 гиг. С какой скоростью выкидывать это в DBF - это еще можно поработать будет, пока не очень быстро. Зато отображается это всё ой как быстро и ой как экономно с точки зрения оперативной памяти.

Это да, разумеется. Грузить в DBF без лишних затрат оперативки. Остается открытым вопрос: может, в fibPlus штатные средства есть, или как-то довольно просто что-то там реализуется... Кажется, что вон оно рядом что-то там, но не могу найти. Еще не нравятся ограничения DBF на поля: нет BigInt, размер строки максимум 254 символа. Хотя, конечно, это всё обходится.

bk0010, понял, спасибо.

IBExpert, к слову, не так давно научился полный фетч делать на данные. Раньше Out of memory давал. Сейчас набирает данных в память, а когда размер занимаемой приложением памяти выпрыгивает за 1.3 гига примерно, он всё набранное скидывает в файл и дальше спокойненько туда фетчит до упора, занимая не больше 80мб оперативки и время от времени спрашивая юзера, не одумался ли он, хочет ли он еще на 15 гиг увеличить размер файла-буфера. Потом бегаем по гриду довольно-таки быстро. Правда вот пытаться отсортировать, кликая по заголовку, не стоит. Вот именно об этом я и говорю.

Может. Открываю 5 форм, в каждой свой запрос, спокойно работает. Firebird 3.0 SS распиливает по потокам раздачу.

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

То есть, мне на форуме нельзя было задать озвученный в топике вопрос? Или о чем Вы, я не понял. Обсуждаем, потому что спрашиваете, зачем мне всё это надо. Я не спрашивал, как мне сменить подход, я спрашивал, есть ли в FibPlus штатное средство. Но за советы спасибо, конечно.

V.Borzov> а когда он сказал: "а найди-ка мне позицию с текстом "АБС", и
V.Borzov> приложение замерло, а, не на подходе к последним строкам еще и умерло.

Ты уже проверял? Сделай небольшую формочку и проверь.

А чего тут проверять. Ctrl+End - и привет, приложение будет висеть, пока не отфетчит всё до последней записи.

Кстати, эти аптеки - это одна сеть аптек с центральной БД
или это разные клиенты? Или как?

Есть сеть центральной базой с 80 аптечными пунктами. Её очень хочется уже на firebird всё перевести, хотя бы центральную базу, ибо Paradox скрипит кое-как, валится на простейших запросах, приходится постоянно изголяться и усложнять пути. Остальные клиенты имеют по 1-3-5-10-15 аптек, им вообще по барабану, firebird у меня или BDE, поэтому и дела с Firebird идут по остаточному принципу. Был клиент с 40 аптеками, но отвалился в прошлом месяце, падла. Наверное, из-за моих заблуждений.