Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Scroll у TDBGrid [D7]

mr. Lonely © (2006-07-23 13:00:00)
Уважаемые Мастера. У меня возникла такая проблема:
на форме есть TDBGrid. подключаю его к любой базе через связку TDataSource - TTable(TQuery). Скролл при этом в гриде может принимать только 3 значения: в начале, в конце и "где-то в середине". Что весьма не удобно.
Если подключать через TClientDataSet, то скролл нормально работает. Я не могу использовать TClientDataSet, тк базу подключаю по сети и в ней немеренно данных (пока TClientDataSet вытягивает все данные все "висит").
Помогите мне решить проблему: Как сделать нормальный скролл у TDBGrid при продключении его через TTable(TQuery).

Desdechado (2006-07-23 15:12:00) [1]
> отсортиртировать и отфильтровать таблицу для упрощения поиска нужной записи
Да, похоже разница автором таки не ощущается :(
Поиск - это позиционирование на записи, и никакого отношения ни к фильтрации, ни к сортировке, ни к выборке не имеет.

Anatoly Podgoretsky (2006-07-23 15:02:00) [2]
Там хватит сложностей. Проще перейти на АДО где это уже реализовано для клиентских курсоров, а если при этом перейти еще и на Д2006 то и колесико будет работать. Среда правда там не устойчивая, но к рантайм замечаний нет, очень стабильно работает и ошибки АДО исправлены, если не пользоваться некоторыми событиями из TAdoConnection.

Desdechado (2006-07-23 14:59:00) [3]
> на форме имеется система фильтров и сортировок
Если ты отличаешь одно от другого, а также фильтр от выборки, то должен понимать, что фильтр сначала достает все на клиента (все миллионы записей), а потом долго и нудно их терзает там, чтоб показать 10 строк. Это фильтрация и именно так работает TTable.
Выборка же заставляет саму СУБД сделать отбор только нужных записей, не нагружая клиента ненужными операциями (особенно, если это по сети -чрезвычайно тормознуто).

> Заранее это спрашивать нельзя.
Чушь. Все эти штуки на "форме для системы фильтрации" и являются "вопросом", на основании которого можно сформировать качественный SQL-запрос к базе.

> как-то "вдруг" стало все работать
А это то, на что я намекал в своем предыдущем посте. О "любой базе". Локальные таблицы используют другой способ при доступе через TTable. И там количество записей известно из заголовка, поэтому бегунок плавный.

Но не обманывай себя, делай лучше правильно, не ерепенься ;)

sniknik (2006-07-23 14:53:00) [4]
> Ну попробуй :-)
да. еще кстати. :о), не все так просто, там еще полностью работу даталинка переписать придется (не уверен, просто видел завязки его работы от событий скрола...)

sniknik (2006-07-23 14:50:00) [5]
> to sniknik: да я обязательно попробую ADODataSet.
не все так просто, попробую. ;о) да у него настроек, на четыре разнотипных компонент хватит... если не знаеш его то попросту не сможеш настроить.

> как-то "вдруг" стало все работать с TTable и TQuery.
если поменял базу то неудивительно. говорю же, не зависит от компонент, зависит от курсора, есть или нет значения recordcount (и recno тоже), а это уже зависит от того какая база, тип, есть для нее у движка режимы клиентский/серверный курсор, настраиваются ли, что стоит по умолчанию (в итоге все сходится на recordcount у датасета)...

> испоьзую стандартную БД BCDEMOS
локальная, файл серверная база, серверного курсора попросту не имеет.

Anatoly Podgoretsky (2006-07-23 14:39:00) [6]
А сначал тянем мегатонны мусора, весьма умно.
Почему заранее спрашивать нельзя, еще как можно и нужно.

Так же можно попробовать перекрыть класс и перехватывать сообщения о перемещении курсора. Самому высчитывать положение курсора.
Ну попробуй :-)

mr. Lonely (2006-07-23 14:34:00) [7]
Уважаемый Desdechado, на форме имеется система фильтров и сортировок, которые как раз и должны помочь пользователю отсортиртировать и отфильтровать таблицу так как ему хочется, для упрощения поиска нужной записи. Заранее это спрашивать нельзя. причем по предметной области пользователь будет чаще пользоваться сортировкой чем фильтром.
to sniknik: да я обязательно попробую ADODataSet.
Так же можно попробовать перекрыть класс и перехватывать сообщения о перемещении курсора. Самому высчитывать положение курсора.
У меня новая проблема: как-то "вдруг" стало все работать с TTable и TQuery. причем вроде это произошло после того как я перекомпилил модуль DBGrid. хотя я не уверен. Странно но я уже 20 минут пытаюсь вернуть проблему :) пока скрол упорно работает как надо. возможно потому что я испоьзую стандартную БД BCDEMOS для тестиования... ничего не понимаю :(

Desdechado (2006-07-23 13:34:00) [8]
Думаю, тут надо думать не о положении ползунка, а о способах работы с БД.
Подключение таблицы целиком вообще обычно не имеет смысла.
Гораздо лучше спросить пользователя, что ему нужно в данный момент и сформировать динамически запрос на основаннии его желаний. Это даст немного строк (если желания нормальные, а не "давай все, там глазами найду"). Глазами более 200 строк просто бессмысленно высматривать, ибо оценить информацию в этом случае человек не в состоянии.
Поведение TTable, описанное тут, связано с тем, что выборка (а это все-таки выборка в случае "к любой базе") кэшируется БДЕ и подсовывается в грид по мере надобности. Поэтому это происходит быстро, но сколько строк получилось в ответе, неизвестно, пока все не вычитаются. Из-за этого только 3 состояния.
Поведение TClientDataset по умолчанию сводится к вычитыванию сразу всей выборки, т.е. количество строк сразу известно, отсюда и плавное поведение бегунка. Но есть у него такое свойство PacketRecords, которое отвечает за чтение по частям. При этом не теряется плавное поведение бегунка. Но! Предупреждаю сразу, что дочитывание происходит асинхронно, поэтому все равно не рекомендую пихать в CDS сразу всю таблицу.
Сначала запрос с ограничением кол-ва строк, потом уже CDS.

sniknik (2006-07-23 13:22:00) [9]
хм... кстати, а возможно я обманываю. есть стандартный такой компанент - ADODataSet, когда он настроен на асиндронную закачку данных, он как раз текущее количество закачанных в recordcount передает... т.е. возможно и грид к нему "подвязанный" будет реагировать адекватно... (проверить надо. кому это надо конечно ;)

sniknik (2006-07-23 13:13:00) [10]
от TTable/TQuery не зависит, зависит от курсора, возможности получить значение recordcount в наборе... в локальном курсоре с выкаченными данными это значение есть, у серверного до завершения закачки (в итоге все одно на клиента перекачивается при Last или FetchAll например) нет (значение -1).
а если нет значения максимума то положение скрола относительно его расчитать сложновато... ;о)

не, теоретически, можно считать от количества уже выкачаного... (ползунок будет смещаться по мере закачки) но в стандартных компанентах такого нет... переделок много потребуется.
поиши нестандартные, может там где есть.

Anatoly Podgoretsky (2006-07-23 13:08:00) [11]
Скролл может принимать столько значений, на сколько у него хватает информации. С TTable(TQuery) хватает только на три значения. С Адо или на три или на множество. С TClientDataSet на множество.
К TDBGrid это не относится, работает как может.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »