| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
большие объемы записей в гридах [D5, IB5.x]
Alexnader © (2002-04-19 23:51:00)Есть проблема, которая заключается в том, что при загрузки больгих объемов данных в грид наблюдаются тормоза при переходе на последнюю запись.
при чем время от количества вариантов растет нелинейно.
Возможно, есть способы обойти это? Т.е. чтобы хоть как-то увеличть произодительность/прикрыть тормоза.
Буду благодпрен за любое предложение.
Мыльте ответы на sh1k@svitonline.com
Спасибо.
Sergey13 (2002-04-24 11:49:00) [1]2Praco © (24.04.02 11:19)
>Универсальный совет - ограничивать объем выборки.
Полностью согласен.
2Alexnader (19.04.02 23:51)
>Есть проблема, которая заключается в том, что при загрузки >больгих объемов данных в грид наблюдаются тормоза при переходе >на последнюю запись.
Твоя проблема в том и заключается, что ты закачиваешь большие объемы. Это ошибка проектирования приложения. Кому нужен грид с 1000 записей если реально он может видеть одновременно 20-30(т.е. 0.2-0.3% от выборки - остальные 99.8% ты скачал с сервера просто так). Надо продумывать механизм навигации по большим таблицам. Например по первым буквам фамилий, по диапазону дат и т.д и т.п. Клиент-серверная технология тем и отличается от файл-серверной, что позволяет тащить на клиента только то что нужно а не все что есть.
Praco (2002-04-24 11:19:00) [2]Моя любимая статья :
http://ib.demo.ru/devinfo/bde.htm
На IB до 6.х я пытался решать проблему так:
Хранимая процедура принимает в качестве параметра кол-во строк, которое нужно вернуть. Дальше For select ... do (здесь счетчик).
Выход по exit... Это в первом приближении.
Но это муторно.
Универсальный совет - ограничивать объем выборки.
Alexandr (2002-04-24 07:08:00) [3]2Фтвкун: Это ты кому?
Фтвкун (2002-04-23 17:39:00) [4]Подумай еще над проблемой обновления данных на клиентском приложении (при изменении оных в базе) каждый раз делать requery ? А не зае... ? Кто - нибудь ответьте !!!!!!!
Alexandr (2002-04-23 08:50:00) [5]1) когда данные закачиваются в грид, или в DataSet, кому как удобнее, то под них на клиентской машине выдяляется место в памяти, и, естественно, чем больше данных, тем больше надо места для их хранения, вплоть до ухода в свопинг.
2) При первом переходе с первой записи на последнюю происходит фетч всех записей с сервера на клиента, т.е. происходит перегон записей по сетке на клиента и при медленной сетке получается медленный фетч, отсюда и тормоза при фетче.
Desdechado (2002-04-22 19:43:00) [6]2 DPetrovich © (20.04.02 16:31)
похоже, да. А вот StringGrid - нет.
2 Alexnader (19.04.02 23:51)
нелинейность наблюдается в завимости от длины записи
DPetrovich (2002-04-20 16:31:00) [7]to kaif ©
Что значит правильный Grid? DBGrid в это смысле правильный?
kaif (2002-04-20 15:45:00) [8]Тормоз происходит не в Grid, а в DataSet. Переход напоследнюю запись вызывает столько раз Fetch (выбор строк), сколько нужно, чтобы добраться до конца набора. Есдинственный выход - не делать такие большие наборы. А сам Grid (если это правильный Grid) просто отображает несколько строк, но не копирует в себя набор.
| |
