Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2002.08.29;
Скачать: [xml.tar.bz2];

Вниз

Время отклика 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-запросов при этом.
....


 
elv   (2002-08-09 11:06) [5]

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 (если используешь). Нормализуй базу данных.



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2002.08.29;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.47 MB
Время: 0.011 c
6-95927
mixVictor
2002-06-17 02:05
2002.08.29
Имя dial-up соединения


1-95754
Squ
2002-08-19 12:52
2002.08.29
Обработка исключений (exception)


1-95797
^Sanya
2002-08-20 00:11
2002.08.29
WinXP Processes


1-95897
^Sanya
2002-08-16 18:44
2002.08.29
Напомните плиз....


1-95792
Riko
2002-08-19 17:39
2002.08.29
Очистки кеша





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский