Фильтрация данных

← →
concord © (2010-05-07 02:21) [0]

Ребят, подскажите пожалуйста простейший способ фильтрации данных в гриде. Т.Е. как пользоваться "Filter"

← →
Германн © (2010-05-07 02:27) [1]

> concord © (07.05.10 02:21)
>
> Ребят, подскажите пожалуйста простейший способ фильтрации
> данных в гриде. Т.Е. как пользоваться "Filter"

В гриде нет никаких фильтров и никакой фильтрации! И никогда не было!

← →
concord © (2010-05-07 02:33) [2]

Неправильно выразился. Фильтрация данных в Дата Сете. Есть ли какой-нибудь простой способ и самая элементарная фильтрация?

← →
concord © (2010-05-07 02:36) [3]

Подробнее.Имеются следующие компоненты: AdoConnection, DataSouce, DataSet есть строка Эдит и кнопка. Нужно отфильтровывать фамилии.

← →
Германн © (2010-05-07 02:42) [4]

> concord © (07.05.10 02:33) [2]
>
> Неправильно выразился. Фильтрация данных в Дата Сете.

В "Дата Сете" нет никакой "фильтрации".

> concord © (07.05.10 02:36) [3]
>
> Подробнее.Имеются следующие компоненты: AdoConnection, DataSouce,
> DataSet есть строка Эдит и кнопка. Нужно отфильтровывать
> фамилии.
>

Про SQL читал что-нибудь? Какой к лешему Filter?

← →
Германн © (2010-05-07 02:47) [5]

"Filter" есть только в компонентах TTable и иже с ними. Советую их сразу выбросить на помойку, если БД не Парадокс.

← →
concord © (2010-05-07 02:47) [6]

Хорошо, задам вопрос совсем просто, как отфильтровать данные в Делфи

← →
Германн © (2010-05-07 02:48) [7]

Если в ADODataSet есть свойство Filter, то я не виноват. :)

← →
Германн © (2010-05-07 02:51) [8]

> concord © (07.05.10 02:47) [6]
>
> Хорошо, задам вопрос совсем просто, как отфильтровать данные
> в Делфи

А не надо их фильтровать в Дельфи. Работая с БД - фильтруй при запросе.

← →
concord © (2010-05-07 02:51) [9]

А если через ADOQuery?

← →
Германн © (2010-05-07 03:01) [10]

> Германн © (07.05.10 02:48) [7]
>
> Если в ADODataSet есть свойство Filter

В Д6 оно есть. :(

← →
Германн © (2010-05-07 04:36) [11]

> concord © (07.05.10 02:51) [9]
>
> А если через ADOQuery?

Не надо.
Не надо!
И ещё раз не надо. TADODataSet имеет полную и достаточную функциональность.

← →
Anatoly Podgoretsky © (2010-05-07 07:20) [12]

> concord (07.05.2010 02:47:06) [6]

Если совсем просто, то присвоить значение свойству Filter := ...

← →
Рамиль_ (2010-05-07 08:46) [13]

Фильтруй селектом, зачем лишнее на клиента тащить?

← →
Вариант (2010-05-07 08:57) [14]

> concord © (07.05.10 02:21)

> Германн © (07.05.10 02:47) [5]

> Германн © (07.05.10 02:51) [8]

А
> не надо их фильтровать в Дельфи. Работая с БД - фильтруй
> при запросе.

> Рамиль_ (07.05.10 08:46) [13]
> Фильтруй селектом, зачем лишнее на клиента тащить?

Это правильно, если надо просто вытянуть ограниченное число данных из часто меняющейся таблицы базы (речь веду о клиент - серверной СУБД).
В случае же работы с "постоянным" справочником ограниченнного размера (скажем до 10 000 записей) для организации быстрого выбора по первым набранным символам - свойства Filter и Filtered достаточно удобны и функциональны. И их использование имеет более высокую скорость отклика, чем постоянное обращение к серверу БД.

Кстати есть и "фильтрующий" грид - из EhLib например и вполне удобный. Конечно в итоге фильтрация там осуществляется через датасет(на выбор Filter или SQL запрос), но это скрыто от оберткой этого грида .

Резюме - выбор варианта зависит от задачи. Универсальный метод - это фильтровать SQL запросом. Но универсальное - это не обязательно лучше решение в каком-то конкретном случае.

TTable/TADOTable + property "Filter" + SQL Server = фильтрация на сервере

/*на сервер улетает where с условием фильтра*/

>Вариант (07.05.10 08:57) [14]
>Это правильно, если надо просто вытянуть ограниченное число данных из >часто меняющейся таблицы базы (речь веду о клиент - серверной СУБД).
>В случае же работы с "постоянным" справочником ограниченнного размера >(скажем до 10 000 записей) для организации быстрого выбора по первым >набранным символам

Если Вы говорите о клиент-серверной технологии, то понятие "правильно" в понимании "клиента" и "сервера" не всегда (далеко не всегда !!!) суть одно и то же :)

>свойства Filter и Filtered достаточно удобны и функциональны. И их >использование имеет более высокую скорость отклика, чем постоянное >обращение к серверу БД.

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

>Кстати есть и "фильтрующий" грид - из EhLib например и вполне удобный.

"Фильтующий" грид как и вообще гриды любые не решат за Вас главную проблему - актуальность данных в таблице. Они лишь предоставляют некий "автоматический" сервис, который многими новичками воспринимается как "волшебники". На самом деле это обман, фикция.

>Конечно в итоге фильтрация там осуществляется через датасет(на выбор >Filter или SQL запрос), но это скрыто от оберткой этого грида .

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

>Резюме - выбор варианта зависит от задачи. Универсальный метод - это >фильтровать SQL запросом. Но универсальное - это не обязательно лучше >решение в каком-то конкретном случае.

вот это правильно. Если задача имеет достаточно локальную "ориентацию", то можно, конечно, фильтровать на клиенте. Но в "концептуальном" смысле такое решение изначально неверно, т.к. чревато ошибками в любой момент.

> [16] MsGuns © (08.05.10 03:02)
> Нет, не удобны и не функциональны. Разве что справочник
> Ваш ограничен несколькими сотнями записей и к тому же мало
> изменяем.

У тебя, разумеется, справочников меньше чем на лимон записей не бывает. 8-)

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

То ли дело полученные SQL-запросом. Века стоят и не меняются. 8-)

← →
Вариант (2010-05-11 12:42) [18]

> MsGuns © (08.05.10 03:02) [16]

> Если Вы говорите о клиент-серверной технологии, то понятие
> "правильно" в понимании "клиента" и "сервера" не всегда
> (далеко не всегда !!!) суть одно и то же :)
>
- этой фразы просто не понял.

> Нет, не удобны и не функциональны. Разве что справочник
> Ваш ограничен несколькими сотнями записей и к тому же мало
> изменяем.
>

Неудобно и не функционально - оставим на вкус и понимание задачи разрабатывающего.

> Ваш ограничен несколькими сотнями записей и к тому же мало
>
> изменяем.

Я так понимаю тут разница между моими строками и твоими только в 10000 у меня и несколькими сотнями у тебя?

Приведу пример, когда выгодно фильтровать на клиенте... В моем приложении есть справочник наименований городов некоего государства, имеет порядка 8000 наименований. Приложение позволяет вести быстрый выбор из справочника по первым набранным буквам(фильтрация осуществляется при каждом изменении строки ввода ). При использовании сервера (выполнение каждый раз LIKE в запросе) скорость реакции ниже, хотя и приемлема(в локальная сети).
Изменения справочника отслеживаются механизмом уведомлений. Но в данном справочнике как сам понимаешь эти изменения происходят крайне редко (и еще раз обратим внимание на предложение выше). Есть аналогичный справочник названий улиц... Не вижу причины не использовать в таких случаях Filter.
И еще - "Отсоединенные наборы данных" - это не всегда зло. И более того, в некоторых случаях других просто может не быть, по крайней мере некоторое время. Пример -web страница...

> Писать программы в задачах, критичных к актуаальности
> информации

Повторю ту часть, с которой не было разногласий - выбор варианта зависит от задачи.

Вариант (11.05.10 12:42) [18]

> В моем приложении есть справочник наименований городов
> некоего государства, имеет порядка 8000 наименований.

Немаленькое государство :) С другой стороны, что такое держать в памяти массив из 8000-20000 строк ? Пустяки.

Фильтрация данных Найти похожие ветки