Скачать: CL | DM;

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 вся ветка

Скачать: CL | DM;



Память: 0.48 MB
Время: 0.008 c