Фильтр

← →
Vint (2002-12-06 12:03) [0]

Уважаемые мастера!

Использую фильтр: Table1.Filter := ...; по одному ключевому полю, если значений уловия фильтра немного, то все нормально, а если значений получается большое количество то вываливается Operation not applicable, подскажите как лечить?

p.s. хотелось бы узнать какое кол-во условий можно записать в Query?

← →
Anatoly Podgoretsky (2002-12-06 12:11) [1]

В Query ничего писать не надо, фильр к нему отношения не имеет, фильр ставится на существующий набор данных

← →
Vint (2002-12-06 12:18) [2]

>Anatoly Podgoretsky © (06.12.02 12:11)

Query я имею в виду как запасной вариант, если с Table1.Filter не прокатит, уж очень условий для фильтра у меня может быть много.

← →
Anatoly Podgoretsky (2002-12-06 12:21) [3]

Нормально работает фильтр и с большим количеством условий, при том фильтр можно поставить и на TQuery, получив набор конечно

← →
Mike Kouzmine (2002-12-06 12:24) [4]

Можно попробовать на onFilterRecord

← →
ЮЮ (2002-12-06 12:31) [5]

Набор значений ключевого поля - это не условие - это извращение. Что заставило тебя этим заниматься?

← →
Vint (2002-12-06 12:44) [6]

>Anatoly Podgoretsky © (06.12.02 12:21)
Я дико извиняюсь - все действительно заработало, что такое, че за ошибка была?

>ЮЮ © (06.12.02 12:31)
поиск заставил (таб. Paradox почти милион строк, 87 полей - вот и вешаюсь :), пробовал даже в таблице просто как в текстовом файле искать, думал быстрее будет - нифига!)

Всем спасибо, еще раз извиняюсь!

← →
ЮЮ (2002-12-06 12:54) [7]

И что это за "сущность" такая многогранная, что 87 полей понадобилось для её описания? :-)

← →
Vint (2002-12-06 13:10) [8]

>ЮЮ © (06.12.02 12:54)
ответ для самых любознательных: первые четыре буквы моего mail ;-)

← →
ЮЮ (2002-12-06 13:23) [9]

Тогда эта таблица предназначена для хранения всего гарема в одной записи :-) Иначе не представляю, чего туда можно напихать

← →
Anatoly Podgoretsky (2002-12-06 13:25) [10]

Vint © (06.12.02 12:44)
Учитывая последнюю информацию, тебе прямой путь к запросам вместо фильтра. Работать будет значительно быстрее, хотя одназначно можно сказать только после полевой проверки, может оказаться что фильтр быстрее или даже OnFilterRecord.

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

← →
ЮЮ (2002-12-06 13:31) [11]

И если это поиск, то откуда ты уже знаешь значение ключевого поля?

← →
Vint (2002-12-06 13:57) [12]

Посвещаю Вас в тонкости работы :)

Существует семь видов гос. регистрации (рождение, смерть, брак, развод, усыновл., уст. отцовства, перемена ФИО).
Заполняется очень большое кол-во разл. инф. по каждому виду: например место рожд., жительства, инф. о родителях, их места рождения и жительства при этом существует куча служебной информации типа мать без отца, супруг разведен, осужден, ребенок без родителей, названия судов, все это с номерами справок, дат, мест выдачи все перечислять - день писать!

Теперь о главном, пришел запрос (УВД, ФСБ, Налоговая, суд и т.д.) разыскивается Володя родился в 1962 г. Кукуево и вперед... умирал, а может женился, приобрел отца, фамилию сменил и т.д. в Вашей области. Короче простор для поиска неограничен.

Ищу так: фильтрую записи подходящие к моему условию и вручную разбираю!

Спасибо за участие, а также всем, кто дочитал, до этого места :)))

← →
Vint (2002-12-06 14:31) [13]

Ну уж до кучи :)
самое критичное место в моей функции поиска это просмотр таблицы от первой записи к последней, (она копируется быстрее, а ведь при этом происходит и чтение и запись!) почему так, и можноли этот процесс оптимизировать, может кто ответит?

← →
Leichenko (2002-12-08 13:15) [14]

Мне кажется, что нужно динамически генерить SQL-запрос только по введенной информации - тогда параметров будет мало!
Плюс делать семь запросов, т.е. отдельный на каждое событие (ты перечислял - рождение, смерть и т.д.), июо делать фильтр на 87 полей не очень хорошо...
Не совсем из этой области, но тем не менее... Например MySQL выполнял запрос с 7 join"ами 25 минут - следствие - выкидывать ненужное! (Кстати Access и MS SQL Svr потратили на такой же запрос 0 сек) =)

Фильтр Найти похожие ветки