Время отклика Refresh растет при перемещении в конец датасета

← →
Влад Утюмов (2002-08-08 18:52) [0]

Я думал такая проблема только с однонаправленными датасетами. Попробовал с TIBTable - то же самое.

На firebird есть тестовая таблица ~80000 записей. Я просматриваю ее в гриде. Пока нахожусь в начале таблицы - Refresh работает моментально. Когда перемещаюсь в конец - возникает задержка секунд на пять. Такая же задержка происходит если из однонаправленного датасета фетчить всю таблицу за раз.

Делаю выводы: при перемещении по датасету увеличивается его буфер. Метод Refresh фетчит буфер _целиком_.

Вопрос: можно ли заставить делать refresh по-умному? чтобы извлекалось разнумное количество записей, не зависимо от того в какой части датасета находимся? Может другие компонеты доступа работают по-другому?

К слову, почему я считаю, что наблюдаемый эффект не есть рулез.
Я работал с 1С. Там Refresh происходит каждые пять секунд по умолчанию. Особых проблем не создает. В конце грида отклик такой же как и вначале. Это dBase в режиме файл-сервер. Почему же IB не может того же.

← →
Polevi © (2002-08-08 18:58) [1]

MIDAS позволяет сделать такое - немного переделаный провайдер и ClientDataset.RefreshRecord дадут нужный результат

← →
elv © (2002-08-08 21:01) [2]

Влад Утюмов
На firebird есть тестовая таблица ~80000 записей. Я просматриваю ее в гриде.
Боюсь прослыть не оригинальным, но зачем пользователю просматривать 80тыс записей. Если он потратит на просмотр каждой записи 1 сек., то потратит на это 22 часа. Так что в такой выборке смысла нет.

Делаю выводы: при перемещении по датасету увеличивается его буфер. Метод Refresh фетчит буфер _целиком_.
Да от "первой" до "текущей".

Вопрос: можно ли заставить делать refresh по-умному? чтобы извлекалось разнумное количество записей, не зависимо от того в какой части датасета находимся?
Сразу возникает вопрос - зачем? Зачем так часто рефрешить записи?У тебя такой интенсивный обмен с БД? Видимые данные могут устареть? Это настолько критично? И т.д. и т.п. и пр.

Может другие компонеты доступа работают по-другому?
Если не ошибаюсь, в FB можно селектом вытягивот N записей. Потом N следующих. Вытягивай хотя бы по 1000 записей.

В конце грида отклик такой же как и вначале. Это dBase в режиме файл-сервер. Почему же IB не может того же.
Потому что так задумано.

← →
Влад Утюмов (2002-08-09 10:38) [3]

Polevi ©
MIDAS позволяет сделать такое - немного переделаный провайдер

RefreshRecord - это хорошая мысль.
А что в провайдере переделывать надо?

elv ©
но зачем пользователю просматривать 80тыс записей.

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

Еще заментил такой ньюанс: чтобы попасть в конец датасета (Ctrl + End на гриде) надо прочитать его весь. Может имеет смысл определять сразу два индекса: возрастающий и убывающий?

Если не сложно, поделитесь опытом, как в Delphi принято делать поиск. В 1С incremental search работает именно как поиск, т.е. он не сужает выборки, а перемещает курсор по таблице. Поэтому пользователь может легко просматривать гриды по 100 000 записей и больше. Похоже, что применяемый в MIDAS и IBDataset способ кэширования делает такой поиск неэффективным. Наверное все нормальные люди реализуют поиск как фильтр?

← →
elv © (2002-08-09 10:54) [4]

А вот смотри что я нашел.
http://www.ibase.ru/devinfo/ClientRefresh.htm

Обновление клиентских наборов данных в InterBase
Юрий Плотников, plotn@euro.ru

В своей первой статье по InterBase хочется остановиться на достаточно нетривиальном вопросе. Тем, кто переходит с локальных СУБД типа Paradox, DBISAM и т.д. возможно, как и мне не хватает автоматического и немедленного обновление данных в таблицах (на стороне клиента) при изменениях, производимыми одновременно несколькими пользователями.

Решение, которое приходит сразу кажется простым – реализовать события в триггерах, при получении которых набор данных обновляется. Также возможно запоминание курсора и возвращения его на место. Но… не гибко – если есть Calculated, Lookup поля, не самый маленький объем данных в таблице – не особо быстро выходит открытие при частых изменениях. Другое решение, предложенное мной сложнее, но, на мой взгляд, гораздо эффективнее. Суть в том, что при получении события обновлять набор данных у других клиентов посредством Delete, Edit, Append, но не генерируя SQL-запросов при этом.
....

Locate со смещением на первую удовлетворяющую условию.
Lookup без смещения.
SetKey/GoToKey со смещение
SetKey/GoToNearest поиск похожей со смещением
FindKey, FindNearest тоже поиск.

Ты сходи на www.ibase.ru.

← →
AlexSam (2002-08-09 11:53) [6]

CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]] INDEX index
ON table (col [, col …]);
Создай индексы ACS и DESC по полям, которые используются при сортировке. Используй TIBQuery и откажись от TIBTable (если используешь). Нормализуй базу данных.

Время отклика Refresh растет при перемещении в конец датасета Найти похожие ветки