В моем варианте весь набор вовсе не тянется. И не перетягивается после ввода каждого очередного символа.
А вот тебе, чтобы найти что-то локальным фильтром придется все засосать на клиента.

> В моем варианте весь набор вовсе не тянется. И не перетягивается
> после ввода каждого очередного символа.

Ну а как тогда, объясни, может я полезное что-то узнаю.

От задачи зависит. Я в своей жизни еще не встречал задачи "поиск неизвестной записи в большой таблице"

Ну я не про жизненный опыт и спрашивал, а про альтернативы.

Ну а как тогда, объясни, может я полезное что-то узнаю.

В шапке грида в колонке открывается инплейс эдитор. Пока в нем не нажмешь энтер или не выйдешь в облать данных, никакие запросы не пересылаются на сервер.

Reindeer Moss Eater ©   (02.04.08 11:07) [42]

Альтернатива - заранее ограничивать выборку заведомо известными значениями. А внутри этой выборки можно и на клиенте поискать, пофильтровать, посортировать, если уж такая нужда возникает. В моей практике необходимость сортировки и фильтрации не встречалась среди должностных задач исполнителей. Для красивости - да, делается. Но жизненной необходимости в этом я, признаться, не видел.

Да понимаете народ, у меня есть таблица, есть 5 комбобоксов, т.е. максимум может быть 5 фильтров, не более. Например, клякнули по первому комбобоксу, отсортировали по данные, потом может быть больше и не надо, а может наоборот, придется и по другим сортировать !!! Вот такая вот задачка. Я вот думаю, может быть ввести данные по все комбобоксам, а потом нажать на кнопку и отработать один запрос. Хотя это наверное неправильно, да и запрос как такой большой построить ?

> В шапке грида в колонке открывается инплейс эдитор.

То есть ты показываешь человеку пустой грид.
Дальше он вводит что-то и только тогда показываешь результат?

Большинство пользоваетлей что я знаю (и я в том числе) начили бы орать: «ААА ве мои данные пропали».
Как можно фильтровать то, незнаю что. Может я вообще фильтроват не буду, а нужное мне и так видно.

А то что ты описал похоже на поиск.

Reindeer Moss Eater ©   (02.04.08 11:07) [42]

Я, разумеется, в своем посте [44] имею в виду задачи OLTP, ибо делать OLAP на медленных каналах, по-моему, садомазохизм.

То есть ты показываешь человеку пустой грид.

Если надо, могу показать пустой. Но обычно он содержит данные.

> То есть ты показываешь человеку пустой грид.
> Дальше он вводит что-то и только тогда показываешь результат?
>


Нет, сначала у меня вываливаются все данные, действительно, я могу и не сортировать !!!

> Если надо, могу показать пустой. Но обычно он содержит данные.

Дак откуда они беруться то?

Если с одной стороны «В моем варианте весь набор вовсе не тянется.», а с другой «В шапке грида в колонке открывается инплейс эдитор.».

То есть при показе грида ты все не тянешь, а задать условие можно только увидев грид. Что-то ты не договариваешь…

Удалено модератором
Примечание: Флудить завязываем

Если с одной стороны «В моем варианте весь набор вовсе не тянется.»,

Включи скл монитор и посмотри чего и сколько будет зафетчено по сети при открытии запроса без where.

Понял наконец, ты хочешь сказать, что тянеш только видимую часть, так?

Сначала показать юзеру ненужные ему данные, а потом уже давать выбрать нужные - жуткий изврат. Обычно для этого сначала поднимается форма с полями для фильтра, на основании введенных данных формируется запрос, выполняется и юзеру показывается уже только нужные ему данные.
Самый хреновый вариант - когда юзер таки не знает, что именно ему надо. Типа - хочу все увидеть и глазками выбрать. Такую ситуевину надо пресекать еще на этапе проектирования и согласования.

АНБ - те же тестикулы, только сбоку.

Ввод критериев поиска и запрос.
Только в одном варианте интерфейс ввода встроен в базовый компонент, а во втором программер на каждый чих дизайнит форму ввода.

> Типа — хочу все увидеть и глазками выбрать.

Это не самый хреновый вариант. А очень удобный и распространенный для небольших наборов данных. Для больших, согласен, нужно фильтороват, сортировать, делать пэйджинг, … до.

> Хотя это наверное неправильно, да и запрос как такой большой
> построить ?

Ограничение на размер запроса - 64 килобайта.
По 5 полям - там вообще миниатюрный запрос будет.
Если база небольшая, (т.е. без проблем мона выкачать всю таблицу на клиента и ничего не падает и не тормозит), то самое простое решение - формировать кажный раз новый запрос на основе введенных юзером условий, учитывая заказанную им сортировку.

> Только в одном варианте интерфейс ввода встроен в базовый
> компонент, а во втором программер на каждый чих дизайнит
> форму ввода.

Как правило :
1) юзер путается в интерфейсе базового компонента
2) возможностей задавать фильтры у базового компонента довольно ограничены, особливо для всяких перечислений и ссылок на справочники, а так же сложных комплексных условий. В форме мона ввести обычный чекбокс и в обработчике извращаться
3) Хорошая запросная система пишется довольно долго и стоит немалых бабок. Я видел только одну, достаточно мощную и понятную для юзера. Ее писали 2 года и лет 5 отлаживали и шлифовали.