большие объемы записей в гридах

← →
Alexnader (2002-04-19 23:51) [0]

Есть проблема, которая заключается в том, что при загрузки больгих объемов данных в грид наблюдаются тормоза при переходе на последнюю запись.
при чем время от количества вариантов растет нелинейно.
Возможно, есть способы обойти это? Т.е. чтобы хоть как-то увеличть произодительность/прикрыть тормоза.
Буду благодпрен за любое предложение.
Мыльте ответы на sh1k@svitonline.com
Спасибо.

← →
kaif (2002-04-20 15:45) [1]

Тормоз происходит не в Grid, а в DataSet. Переход напоследнюю запись вызывает столько раз Fetch (выбор строк), сколько нужно, чтобы добраться до конца набора. Есдинственный выход - не делать такие большие наборы. А сам Grid (если это правильный Grid) просто отображает несколько строк, но не копирует в себя набор.

← →
DPetrovich (2002-04-20 16:31) [2]

to kaif ©
Что значит правильный Grid? DBGrid в это смысле правильный?

← →
Desdechado (2002-04-22 19:43) [3]

2 DPetrovich © (20.04.02 16:31)
похоже, да. А вот StringGrid - нет.

2 Alexnader (19.04.02 23:51)
нелинейность наблюдается в завимости от длины записи

← →
Alexandr (2002-04-23 08:50) [4]

1) когда данные закачиваются в грид, или в DataSet, кому как удобнее, то под них на клиентской машине выдяляется место в памяти, и, естественно, чем больше данных, тем больше надо места для их хранения, вплоть до ухода в свопинг.
2) При первом переходе с первой записи на последнюю происходит фетч всех записей с сервера на клиента, т.е. происходит перегон записей по сетке на клиента и при медленной сетке получается медленный фетч, отсюда и тормоза при фетче.

← →
Фтвкун (2002-04-23 17:39) [5]

Подумай еще над проблемой обновления данных на клиентском приложении (при изменении оных в базе) каждый раз делать requery ? А не зае... ? Кто - нибудь ответьте !!!!!!!

← →
Alexandr (2002-04-24 07:08) [6]

2Фтвкун: Это ты кому?

← →
Praco (2002-04-24 11:19) [7]

Моя любимая статья :
http://ib.demo.ru/devinfo/bde.htm

На IB до 6.х я пытался решать проблему так:
Хранимая процедура принимает в качестве параметра кол-во строк, которое нужно вернуть. Дальше For select ... do (здесь счетчик).
Выход по exit... Это в первом приближении.
Но это муторно.
Универсальный совет - ограничивать объем выборки.

← →
Sergey13 (2002-04-24 11:49) [8]

2Praco © (24.04.02 11:19)
>Универсальный совет - ограничивать объем выборки.
Полностью согласен.

2Alexnader (19.04.02 23:51)
>Есть проблема, которая заключается в том, что при загрузки >больгих объемов данных в грид наблюдаются тормоза при переходе >на последнюю запись.
Твоя проблема в том и заключается, что ты закачиваешь большие объемы. Это ошибка проектирования приложения. Кому нужен грид с 1000 записей если реально он может видеть одновременно 20-30(т.е. 0.2-0.3% от выборки - остальные 99.8% ты скачал с сервера просто так). Надо продумывать механизм навигации по большим таблицам. Например по первым буквам фамилий, по диапазону дат и т.д и т.п. Клиент-серверная технология тем и отличается от файл-серверной, что позволяет тащить на клиента только то что нужно а не все что есть.

большие объемы записей в гридах Найти похожие ветки