проверка попадания записи в фильтр - NAV: Программирование

Nosta · 31.05.2010, 15:44

всем привет!

есть нетривиальная (как по мне) задачка:
имеется строка фильтра по полю А для таблицы Х. например, 120..158
имеется значение поля А. например, 136
необходимо проверить попадает ли значение 136 в отфильтрованный набор 120..158?

сначала решил просто и прямо: накладываю фильтр и перебираю записи пока не найду нужное мне значение. если нету, значит не попадает
потом решил дописывать к строке фильтра доп. условия: '('+фильтр+')&'+значение. если находит первую запись, значит попадает.

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

есть ли более быстрые и изящные способы определения вхождения в отфильтрованный набор?

Milk · 31.05.2010, 16:02

Проще всего, наверное, воспользоваться группами фильтров. Наложить на одном уровне 120..158, на другом 136, и посмотреть, найдется ли запись.

Nosta · 31.05.2010, 16:19

Цитата:

Сообщение от Milk

Проще всего, наверное, воспользоваться группами фильтров. Наложить на одном уровне 120..158, на другом 136, и посмотреть, найдется ли запись.

осмелюсь показаться наглым: а можно посмотреть как это реализовать в коде? никогда не работал с группами фильтров (

Fordewind · 31.05.2010, 16:29

Цитата:

Сообщение от Nosta

всем привет!

есть нетривиальная (как по мне) задачка:
имеется строка фильтра по полю А для таблицы Х. например, 120..158
имеется значение поля А. например, 136
необходимо проверить попадает ли значение 136 в отфильтрованный набор 120..158?

сначала решил просто и прямо: накладываю фильтр и перебираю записи пока не найду нужное мне значение. если нету, значит не попадает
потом решил дописывать к строке фильтра доп. условия: '('+фильтр+')&'+значение. если находит первую запись, значит попадает.

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

есть ли более быстрые и изящные способы определения вхождения в отфильтрованный набор?

А откуда растут ноги у такой задачи? Я что-то не слышал, что бы фильтры криво отрабатывали.

Raul · 31.05.2010, 16:32

Если есть запись, для которой нужно проверить попадает она в какой-то отфильтрованный набор, то нужно
1. установить фильтры на нужные поля этой записи Rec.SETFILTER или использовать Rec.SETVIEW
2. вызвать Rec.FIND, если запись попадает в набор то вернется TRUE

Nosta · 31.05.2010, 16:38

Цитата:

Сообщение от Fordewind

Цитата:

Сообщение от Nosta

всем привет!

есть нетривиальная (как по мне) задачка:
<.........>
потом решил дописывать к строке фильтра доп. условия: '('+фильтр+')&'+значение. если находит первую запись, значит попадает.

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

есть ли более быстрые и изящные способы определения вхождения в отфильтрованный набор?

А откуда растут ноги у такой задачи? Я что-то не слышал, что бы фильтры криво отрабатывали.

задача в принципе простая: ограничить пользователю выбор допустимых значений по полю Х в зависимости от значения поля Y. например, если поле Х попадает в диапазон 125А..146Р, то допустимые значения для поля Y должны быть в диапазоне 'B..I|S..V'. и вот когда пользователь пытается ввести в поле Y, например, К, то система должна его грязно выругать.

Milk · 31.05.2010, 16:43

Цитата:

Сообщение от Nosta

Цитата:

Сообщение от Milk

Проще всего, наверное, воспользоваться группами фильтров. Наложить на одном уровне 120..158, на другом 136, и посмотреть, найдется ли запись.

осмелюсь показаться наглым: а можно посмотреть как это реализовать в коде? никогда не работал с группами фильтров (

Например, написать

recX.FILTERGROUP(2);
recX.SETFILTER(A, '120..158');
recX.FILTERGROUP(0);
recX.SETFILTER(A, '136');
if recX.FINDFIRST THEN ...

и не забыть потом сделать записи RESET, чтобы снять фильтры.

Цитата:

Сообщение от Raul

Если есть запись, для которой нужно проверить попадает она в какой-то отфильтрованный набор, то нужно
1. установить фильтры на нужные поля этой записи Rec.SETFILTER или использовать Rec.SETVIEW
2. вызвать Rec.FIND, если запись попадает в набор то вернется TRUE

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

Raul · 31.05.2010, 16:49

Цитата:

Сообщение от Milk

Цитата:

Сообщение от Nosta

Цитата:

Сообщение от Milk

Проще всего, наверное, воспользоваться группами фильтров. Наложить на одном уровне 120..158, на другом 136, и посмотреть, найдется ли запись.

осмелюсь показаться наглым: а можно посмотреть как это реализовать в коде? никогда не работал с группами фильтров (

Например, написать

recX.FILTERGROUP(2);
recX.SETFILTER(A, '120..158');
recX.FILTERGROUP(0);
recX.SETFILTER(A, '136');
if recX.FINDFIRST THEN ...

и не забыть потом сделать записи RESET, чтобы снять фильтры.

Цитата:

Сообщение от Raul

Если есть запись, для которой нужно проверить попадает она в какой-то отфильтрованный набор, то нужно
1. установить фильтры на нужные поля этой записи Rec.SETFILTER или использовать Rec.SETVIEW
2. вызвать Rec.FIND, если запись попадает в набор то вернется TRUE

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

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

Milk · 31.05.2010, 16:54

Насколько я понимаю, если ключ не первичный, FIND может найти не ту запись. В хелпе к функции FIND специально это отмечается:
If the current key is not the primary key, there is a chance that several records might have the same values in current key fields.

Raul · 31.05.2010, 17:00

Цитата:

Сообщение от Milk

Насколько я понимаю, если ключ не первичный, FIND может найти не ту запись. В хелпе к функции FIND специально это отмечается:
If the current key is not the primary key, there is a chance that several records might have the same values in current key fields.

Речь идет о вызове FIND без параметров, что равнозначно FIND('='), при таком вызове к существующим фильтрам на записи прибавляется фильтр по первичному ключу/ключам. Такой вызов FIND в принципе не может вернуть больше одной записи.

Nosta · 31.05.2010, 17:32

с фильтр группами отработало на ура. спасибо!

Storkich · 01.06.2010, 13:25

Задача тривиальная! Название темы не соответсвует содержимому.

Вот задачка чтоб подумать. В настроках есть строка с навороченым фильтром(250 символов). При вставе в таблицу необходимо проверять. соответсвует ли значение поля указанному фильтру.

Storkich · 01.06.2010, 13:33

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

Storkich · 01.06.2010, 13:45

Цитата:

Сообщение от Raul

Цитата:

Сообщение от Milk

Насколько я понимаю, если ключ не первичный, FIND может найти не ту запись. В хелпе к функции FIND специально это отмечается:
If the current key is not the primary key, there is a chance that several records might have the same values in current key fields.

Речь идет о вызове FIND без параметров, что равнозначно FIND('='), при таком вызове к существующим фильтрам на записи прибавляется фильтр по первичному ключу/ключам. Такой вызов FIND в принципе не может вернуть больше одной записи.

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

romeo · 29.06.2010, 23:41

Цитата:

Сообщение от Storkich

Цитата:

Сообщение от Raul

Цитата:

Сообщение от Milk

Насколько я понимаю, если ключ не первичный, FIND может найти не ту запись. В хелпе к функции FIND специально это отмечается:
If the current key is not the primary key, there is a chance that several records might have the same values in current key fields.

Речь идет о вызове FIND без параметров, что равнозначно FIND('='), при таком вызове к существующим фильтрам на записи прибавляется фильтр по первичному ключу/ключам. Такой вызов FIND в принципе не может вернуть больше одной записи.

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

Ага. Написать можно было вот так.

Код:

Rec.SETFILTER(Code, '120..158');
Rec.Code := '136';
Exist := Rec.FIND;