forum.clarionlife.net

Здравствуйте все!

Вопрос такой...

Возможно ли задать сортировку list'boxa (по порядку, т.е алфавиту и т.п.), по второй, третьей, вообщем по любой (только не по первой) компоненте(полю) многокомпонентного ключа.

Дмитрий Гудков gudkov_net@mail.ru
Написал: ClaList(2)

да, можно

КАК???
Написал: gudkov(146)

Для начала вам сюда http://forum.clarionlife.net/topic.php? ... 1096444019.

Если пишете на ABC:
1. Если размер таблицы небольшой то можно
BRWxxx.SetOrder('REP:MyField1,REP:MyField2')
или использовать additional sort order при убранном ключе на файле
Небольшой размер таблицы..мммм...записей 100-200.

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

Если пишете на C6:
активизируйте галку, что то вроде, "разрешить сортировку на колонках листбокса" - кликайте - и будет вам сортировка. Реализовано, по моему, примерно как сказано выше в п.1.

ИМХО
применять SetOrder очень удобно только в Report-ах, в остальных случаях нет.

Написал: PAA(27)

Хммм....
Это все конечно интересно...

Но, я пишу на Legacy(C5.5 ШВС), а насчет много много ключей по полям, так не получиться. Потому что я использую rangelimit по очереди значений для брауза, а работает этот фильтр только тогда, когда поле по которому фильтруется, стоит в ключе первым(или единственным), поле же это используется только для фильтра, т.е. сортировать по нему мне ничего не надо.
Вот я и спрашиваю, можно ли сортировать в рантайме по другим компонентам ключа или нет, если можно, то как это сделать в legacy(пусть даже руками писать). Потому как с отдельными ключами, конечно можно, но это переустановка View, т.е., как следствие замедление работы, проблемы со ScrollTop и ScrollBottob(после этих событий, вьюшка переустанавливается по ее так сказать родному ключу, и приходиться насильно ставить ее так как мне надо, т.е. гимор), и т.п.
Может это делается как то легче???
Написал: gudkov(146)

Можно. Никаких проблем, кроме эффективности. Надо просто понять, что когда выборка отсортирована по тому полю, по которому идет фильтрация, то выборку можно сделать не читая из таблицы ничего лишнего. Т.е. максимально эффективно. Эта типовая ситуация реалзуется через Range Limit. Если такой сортировки нет, то для постороения выборки придется прочитать ВСЮ таблицу, потому что искомые значения могут находиться как в начале, так и в конце таблицы. В этом случае Range Limit НЕ задаешь, а в Record Filter просто записываешь условие отбора.

WBR, Nick Tsigouro mailto:nick@arsis.ru
Написал: ClaList(2)

Но, я пишу на Legacy(C5.5 ШВС),

С этого всегда и нужно начинать.

а насчет много много ключей по полям, так не получиться. Потому что я использую rangelimit по очереди значений для брауза, а работает этот фильтр только тогда, когда поле по которому фильтруется, стоит в ключе первым(или единственным), поле же это используется только для фильтра, т.е. сортировать по нему мне ничего не надо.

Рекомендую всеж-таки определиться с понятиями Таки по очереди rangelimit или все-таки фильтр? Как определиться? Посмотреть внутрь исходного текста. Это ведь ШВС, там все ясно и понятно.
Про то, что допустим только первый компонент ключа - поверю на слово.

Вот я и спрашиваю, можно ли сортировать в рантайме по другим компонентам ключа или нет, если можно, то как это сделать в legacy(пусть даже руками писать). Потому как с отдельными ключами, конечно можно, но это переустановка View, т.е., как следствие замедление работы, проблемы со ScrollTop и ScrollBottob(после этих событий, вьюшка переустанавливается по ее так сказать родному ключу, и приходиться насильно ставить ее так как мне надо, т.е. гимор), и т.п.
Может это делается как то легче???

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

С уважением,
Владимир Смелик vovs@bigfoot.com
Написал: ClaList(2)

Понятно, то есть тут надо выбирать, либо скорость либо сортировка какая надо.
Кстати странно, rangelimit по очереди в ШВС это обычный {prop:filter} в строку которого пихается вся очередь для выборки, но работает быстро(куда быстрее просто прописанного фильтра).

Дмитрий Гудков
Написал: ClaList(2)

Если у тебя нет ключей, которые удовлетворяют данным требованиям сортировки - только обычный фильтр.
Кстати, и с фильтром следует так-же быть внимательным - если предполагается большое кол-во отфильтрованных записей (больше ~30% от всего кол-ва), то можно использовать фильтрацию самой VIEW - она сделает это быстрее обычного цикла прямо в коде.
Если-же предполагается мало отфильтрованных записей, то в некоторых случаях обычный цикл перебора прямо в коде оказывается быстрее VIEW.
Ну, или переход на SQL - там вся фильтрация производится прямо на сервере и поэтому - быстро.

Кстати странно, rangelimit по очереди в ШВС это обычный {prop:filter} в строку которого пихается вся очередь для выборки, но работает быстро(куда быстрее просто прописанного фильтра).

Ну так VIEW - не просто "тупой" цикл отбора записей по заданным параметрам! Там есть некие элементы "интелекта" - переданный фильтр анализируется и по его результатам выбирается самый подходящий ключ выборки, если, конечно, перед открытием VIEW разработчик сам не задал приоритетный ключ выборки. Ну и, естественно, не следует из-за лени задавать в фильтре короткие выражения с использованием функций типа INRANGE/INLIST.
Т.е., в любом случае выражение:
'(F:CODE=1) OR (F:CODE=4) OR (F:CODE=7)' будет обработано быстрее выражения: 'INLIST(F:CODE,1,4,7) <> 0'.
Ну и, кроме того, анализатор фильтра просто не сможет из-за этих функций подобрать правильный ключ выборки.

Все это, естественно, справедливо ТОЛЬКО для достаточно больших обьемов.
На моей машине (P4-3200-1G), к примеру, каталог клиентов размером ~100000 записей "шерстится" VIEW практически независимо от фильтра:
- без фильтров чтение всех записей составляет ~1.5 сек.
- с ЛЮБЫМ простым фильтром, независимо от того, какие поля там присутствуют (ключевые/НЕключевые), время выборки + чтение отобранных записей занимает от 1 до 1.6 сек.
Расброс времени связан только с кол-вом записей в выборке.

Кстати, а вот обычный обход всех записей по Next занимает всего 1 сек. Естественно, если обход в файловом порядке - по ключу время обычного обхода увеличивается на порядок.
А если еще использовать и rangelimit-выражение по ключу, то время еще меньше - в зависимости от кол-ва записей в выборке.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Написал: ClaList(2)

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

Дмитрий Гудков
Написал: ClaList(2)

Да нет, думаю - не стоит переделывать.
Во-первых, как я написал, все будет зависеть от выборок. А тут уже не угадаешь!
Да и не думаю, что даже в самых лучших случаях получите ощутимое ускорение.
Поэтому, имхо, универсальный VIEW-движек будет работать нормально.
Хотя, если есть желание и время оптимизироват ради процентов выигрыша в некоторых случаях - вперед!

=============================
С уважением, Олег А. Руденко
Написал: ClaList(2)

Понятно, то есть тут надо выбирать, либо скорость либо сортировка какая надо.
Кстати странно, rangelimit по очереди в ШВС это обычный {prop:filter} в строку которого ...

Именно это я и имел ввиду. Это не rangelimit, а обычный фильтр.

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

Быстро т.к., во-первых, используется только набор строгих равенств и, во-вторых, по первому компоненту ключа.

С уважением,
В.Смелик
Написал: ClaList(2)