Форум: "Базы";
Текущий архив: 2002.06.03;
Скачать: [xml.tar.bz2];
ВнизDBGrid и тормоза Найти похожие ветки
← →
Alexnader (2002-04-29 21:12) [0]В моей задаче в DBGrid через DataSource загоняются периодически (по запросу пользователя) довольно большие объемы данных (100-300 тысяч записей).
Когда я просто юзаю датасет и отфетчиваю все записи, то все ok, когда приделываю Datasource, тоже. А когда dbgrid сопоставляю с datasource, то через нескольок запусков возникают сильные тормоза.
Что делать и кто виноват?
← →
Anatoly Podgoretsky (2002-04-29 21:19) [1]Что делать с такими объемами, все ли в порядке в консерватории?
← →
Alexnader (2002-04-29 21:26) [2]Желание заказчика.
← →
Mike_Goblin (2002-04-30 10:32) [3]Попробуй перед записью большого объема инфы у датасета делать
DisableControls, после EnableControls. Данная метода отключает/включает отрисовку в data-aware компонентах, связанных с DataSet
← →
Desdechado (2002-04-30 10:40) [4]> Желание заказчика.
Более 500-1000 записей глазками не отсмотришь. Заказчика нужно убедить, что сделать 100 запросов по 1000 записей легче и быстрее, чем 1 запрос на 100000 записей.
Тем более, что это действительно так :)
Так что ограничивай выборки. Просто заказчик привык работать с простынями бумажных документов, чтобы все было перед глазами (но одновременно на все простыни смотреть глаз все равно не хватит).
← →
Johnmen (2002-04-30 10:43) [5]Если действительно надо гонять такие объемы (я грущу :))))))), то
чтобы было более-менее быстро, необходимо :
- либо написать свой специализированный компонент доступа
- либо взять уже написанный кем-то
← →
Alexnader (2002-04-30 17:54) [6]Проблема не в том, что загрузка данных занимает много времени, а в том, что ЧЕРЕЗ НЕСКОЛЬКО ЗАПУСКОВ занимает чрезмерно много времени.
← →
Slava (2002-04-30 19:02) [7]Это специально для таких паталогических случаев
http://www.devrace.com/download.php?url=http://www.devrace.com/files/gb_datasets.zip
"gb_DataSets Components " is a set of components providing an opportunity of normal navigation on large data sources - tables and queries. The set consists of two components: TgbDataSet and TgbTable. The first one provides caching, navigation, editing on a random data set which has returned SQL-query, the second provides similar functionality on a separate table. Unlike standard IBX- and FIBPlus-DataSets, gb_DataSets never download the all data from the InterBase server. So, the basic distinction between such components as IBTable, IBDataSet, IBQuery, pFIBDataSet, consists in cache architecture and
server request technique.
← →
Alexnader (2002-04-30 22:40) [8]Благодарю за инфу. Попробую.
А со стандартными компонентами такого вытворять нельзя?
← →
dimanchik (2002-05-03 00:51) [9]Скорей всего размер записи велик.
Попробуй разбить таблицу на несколько.
← →
Alexnader (2002-05-04 15:39) [10]2Mike_Goblin : стало еще медленнее
2All: может быть, грид не освобождает память? первый раз-то все нормально.
И если да, то как го заставить это делать?
← →
Serg Vostrikov (2002-05-12 10:00) [11]Привет, Александр!
Правду тебе люди говорят - нельзя такие объемы гонять. Во-первых, большая нагрузка на сеть, во-вторых, увеличение вероятности deadlock, в третьих, тебе все равно придется к этому поиск цеплять, поскольку человек не может "глазками" обрабатывать объем в несколько тысяч записей.
Любое требование заказчика должно быть оправдано. Спроси его, ЗАЧЕМ ему нужно все это видеть? Что он с этим будет делать? И вот когда ответит конкретно, тебе станет ясно, как решить проблему без вытаскивания всех записей.
Ну и в любом случае, IBX не очень аккуратно память расходует, поэтому если уж совсем выбора нет, то FIBPlus будут по-быстрее. Можешь еще IBO попробовать. Там есть компоненты, которые совместимы только с IBO-контролами. Они, по идее, должны быть под это дело оптимизированы. Однако, в этом случае, ты не сможешь использовать параллельно для этого же запроса стандартные контролы. Выбирай :).
Но я бы на твоем месте, конкретно поговорил бы с заказчиком. Именно в нем, в данном случае, проблема.
gb_datasets для IBX и FIBPlus тут скорее всего не помогут, поскольку они являются как бы оптимизированной TIBTable :) с двусторонней навигацией. Твоя же проблема в слишком больших объемах данных гоняемых с сервера на клиента.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.06.03;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.005 c