Приветствую,

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

Есть CacheModelOptions, который при выполнении определенных условий вживую будет лазить в базу за данными, храня в памяти ограниченное кол-во записей, и вроде замечательно выглядит, но не всё гладко там, например с recno, может, еще что-то какие глюки полезут... Да и от базы отцепиться хотелось бы.

Спасибо.

Смотрел, туплю. Подскажите, если не сложно.

Гаджимурадов Рустам,

Запрос в tpFibdataset выполняется для расчета сумм, то есть придется отфетчить все записи, и для отображения результата запроса в гриде в приложении. В стандартном варианте tpFibDataset загрузит все считанные с сервера данные в оперативную память, а память у нас ограниченная, особенно, если приложение 32 разрядное. То есть, если памяти не хватит - получаем Out of memory. Значит, мы либо сбрасываем считанные результаты в кэш на диск, с которого и показываем результаты запроса юзеру, в гриде, например, как это делает BDE, и мы даже и не паримся, сколько там сожрало приложение памяти оперативной и не получит ли оно Out of memory. Второе решение - выставить pfibdataset.cachemodeloptions.cachemodelkind в cmkLimitedBufferSize, и тогда pfibdataset будет подкачивать отображаемые данные по мере их надобности: надо в last выставить - скачает последние записи, покажет, а надо в First - скачает первые, покажет, а надо пробежать от first до last, то будет выкачивать новые по мере прохождения по датасету, а старые выгружать из памяти, а когда к ним обращаемся снова - скачивать их снова с сервера. Во втором решении, вроде, всё прекрасно, но после выполнения запроса мы остаемся во взаимодействии с сервером. Хотелось бы скачать все данные запроса целиком, пусть в кэш на диске, потом отцепиться от сервера, и разглядывай их сколько хочешь в своем гриде, сколько бы их там не было тыщ строк. Штатного средства в FibPlus для этого нет, похоже? Или не нахожу просто?

ъъъъъ,
Люди писали здесь, на форуме, что FibPlus не работает в 64 разрядных приложениях. То ли это означало, что и не откомпилится, то ли это означало, что будет работать некорректно, и надо допиливать - не знаю. У меня, к сожалению, Delphi XE. А так - да: возможности в использовании оперативки расширяются.

ъъъъъ,

Хмм, интересно, спасибо. Что-то я проглядел этот топик и приуныл. Правда, у меня всё равно XE, а на последний Delphi перейти доходы с бизнеса не позволяют, но это вот уже и правда оффтоп :)

Мимопроходящий,
Для расчета сумм надо смотаться до конца один раз. Потом надо отобразить в гриде в приложении и, кстати, вернуться на первую запись. При cmkLimitedBufferSize, кстати, датасет призадумается, так как пойдет фетч уже первых записей, которые он давно выгрузил из памяти.

ъъъъъ,

Да просто тупо "журнал продаж", например. Полей много, максимально подробно выведена каждая строка. Вот делаем запрос, видим результат. Вот увеличиваем диапазон дат - out of memory. Всё.

Юзер знает, что есть журнал продаж, там сумма итого. Листать ему и не надо, может. Дает диапазон хрен знает какой и пытается вывести отчет. При больших диапазонах программа не справляется. Тут мы либо ограничиваем возможности этого отчета, запрещая юзеру выводить больше чем вот столько-то данных, чего хотелось бы избежать, либо исходим из того, что приложение может вывести всё, что захочет клиент, за счет оперативной памяти, за счет дискового пространства, или, в конце концов, за счет постоянных обращений к серверу. Но должно работать.

Разве по такому датасету можно свободно бегать в гриде взад-вперед?

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

Окно с выводом сумм и с гридом, отображающим все данные. Об этом говорю.

ъъъъъ,

Что такое "генератор отчетов"?

Вот журнал продаж, за 3 недели, по всем 80 аптекам предприятия. 500 тыс записей в результате выдал. Выдавал (то есть полный фетч) 170 секунд. Приложение в памяти заняло 1.1 гига. pfibdataset.savetofile() выгрузил всё содержимое в файл размером 900мб, кстати, за какие-то 4 секунды, кстати. Теперь выгружаю полученный результат в DBF-файл с помощью TDBF. Получился файл размером 6 гиг. Если открыть этот файл в TDBF (5 секунд на открытие) и отобразить его в гриде, то приложение занимает всего 27мб в оперативке, и летаем с первой до последней записи циклом while not eof do next. за 6 секунд. Сиди, разглядывай свой грид, сколько влезет, всё летает.

В своем рабочем BDE-приложении, работающем с базой Paradox, этот журнал выходит на том же компе за 5 минут. Листай сколько хочешь, приложение занимает 100мб в оперативке. Правда, там многие поля калькулируются на лету, что на скорость листания влияет, но не так критично. В новом приложении с Firebird-базой я все поля в таблице пытаюсь выводить одним запросом, отдельным потоком к тому же, потом передаю в форму с гридом.

Гаджимурадов Рустам,

Ага, значит, фастрепорт. Ну, фастрепорт я использую для печати уже готового результата, если клиенту захотелось его напечатать, что далеко не всегда. Как стандартный отображатель данных на экране я его не использую. Гораздо интереснее, по-моему, всегда вывести в окошке с гридом и суммами, откуда и выбросить можно хоть куда, хоть в эксель, чем часто пользуются аналитики, и еще куча всяких действий, например перехода в другие документы и формы. И кнопка печати вот, как одно из действий, а там куча разных вариантов этой печатной формы, у каждого клиента своя. То есть в печатную форму передается датасет этот, еще какие-нибудь параметры, а там рисуй что хочешь, на месте у клиента прямо. Но чтобы сразу на экран готовое через фастрепорт - это только в случае, если какой-то совсем нестандартный отчет, который не включается в экзешник, а только у этого пользователя. Да и то, как там с потоками работать в фастрепорте - еще разбираться надо будет. Сейчас же я открываю форму, указываю параметры запроса (период дат, например), нажимаю кнопку "открыть", дальше форма думает, а я могу в программе другими делами заниматься, еще пару отчетов-форм открыть, например.

Гаджимурадов Рустам,
Что неправильно, расскажите, если не сильно сложно.

ъъъъъ,
У вас нет такого отчета, как журнал продаж?

Гаджимурадов Рустам,
У кого у нас? Я единственный. Научить некому.

Никому не интересно это в виде превью в фастрепорте. В окне у людей куча кнопок с кучей всяких действий.

Хорошо, рассуждаем: вот есть отчет "Журнал продаж". Я не знаю, зачем он им там нужен, но еще лет 22 назад меня попросили такой отчет сделать. Сделал. У кого-то это больше, у кого-то это меньше. Вот у клиента самого жирного сейчас за один день по всем АП журнал в сумме выдает 36184 строк . Далее я встаю перед выбором: либо запрещать клиенту этому открывать этот отчет более чем за 1 день, потому что это зашквар, то есть признаться в том, что этот отчет не работоспособен на таких объемах. Либо заставить его высунуть всё это так или иначе, а юзер уж пусть сам решает, где ему удобнее смотреть суммы - в журнале отпуска товаров или в сводной ведомости реализации по складам, где 80 строк. Какой наш выбор?

Гаджимурадов Рустам,
Старой BDE системе 22 года, я создал её в 1998 году. Сейчас пытаюсь, наконец, перетащить в Firebird, а фактически - новая система пишется, с нуля практически, но на основе всё тех же аналитических форм. Но, поскольку подходы при работе с данными совершенно другие тут, то постоянно приходится ломать мозги на вещах, над которыми раньше даже и не задумывался.

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

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