Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
07.09.2007, 18:00
|
|||
|---|---|---|---|
|
|||
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
Есть GRID, в котором отображается подчиненная таблица. Фильтр установлен свойством ChildOrder. Необходимо в рамках данного фильтра организовать сортировку по другому полю. Если ставлю фильтр при помощи SET ORDER TO, сбрасывается предыдущий и теряется связь с родительской таблицей - GRID вообще ничего не отображает. Можно ли сделать фильтрацию без индекса или каким- то способом установить два order'а последовательно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.09.2007, 18:14
|
|||
|---|---|---|---|
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
Фильтр ставится при помощи SET FILTER TO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.09.2007, 18:20
|
|||
|---|---|---|---|
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
Если речь идет о том, чтобы в пределах связанных записей изменить порядок сортировки, то это можно сделать при помощи составного индекса по частичному совпадению ключа. Вот здесь описано что именно имеется в виду http://www.foxclub.ru/articles/index.php?id=36#OrdinaryRelationship Однако это имеет смысл, если порядок сортировки один и тот же. Т.е. можно обойись одним составным индексом. Если же порядок сортировки заранее не известен, то имеет смысл вместо RELATION делать выборку. Т.е. в Grid отображать не собственно таблицу, а выборку из нее отсортированную нужным образом. Выборку можно сделать любым удобным способом через Select-SQL, Local View или CursorAdapter ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.09.2007, 18:53
|
|||
|---|---|---|---|
|
|||
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
Виноват, SET ORDER TO - не фильтр, конечно, порядок А как со скоростью при работе по частичному совпадению индекса? Потому что когда я пытался вытащить нужные записи по SET FILTER TO, а потом накатить нужный мне ORDER, застрелиться было можно, пока дождешься обновления формы :( (обе таблицы не маленькие) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.09.2007, 23:35
|
|||
|---|---|---|---|
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
Фильтр (SET FILTER TO) - это не что-то вычисленное один раз, а некий способ перебора записей. Т.е. при наложении фильтра сразу ничего не происходит, поэтому сама команда проходит мгновенно. Но затем, при попытке перейти на очередную запись, FoxPro проверяет удовлетворяет ли данная запись условию фильтра. Если нет, то запись пропускается и проверяется следующая запись. Для отображения в Grid надо найти столько записей удовлетворяющих фильтру, сколько строк видно в Grid одномоментно. При первом открытии поиск таких записей начнется с самого начала таблицы. Если количество записей НЕ удовлетворяющих условию фильтра мало, то поиск нужного количества записей произойдет быстро. Но вот если фильтр отбрасывает большое количество записей, то пока будет найдено нужное количество записей может пройти достаточно много времени. Причем выставленный главный индекс еще замедляет процесс поиска. Правда, в VFP9 этот процесс для Grid можно оптимизировать (ускорить) если установить свойство Grid.Optimize = .T. Но это имеет смысл только в том случае, если по тому полю или выражению, по которому выполняется фильтрация есть индекс. Связка по SET RELATION выполняется очень быстро, поскольку основана на индексе. Здесь торможения заметно не будет. Но такая связка годится только для простых случаев отображения данных. Если предполагается разнообразная сортировка или дополнительная фильтрация записей подчиненной таблицы, то лучше делать выборку по коду главной таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2007, 10:37
|
|||
|---|---|---|---|
|
|||
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
В грид выбирается список телефонов предприятия по коду предприятия. Т.е. как раз случай, когда удовлетворяет условию мало записей, и SET FILTER работает очень медленно. SET RELATION устраивает вполне в плане выборки, но нужно еще внутри этой выборки сортировать по важности, например. Сортировку хотелось бы произвольную, чтобы пользователь сам устанавливал порядок, для этого создал отдельное поле. Сейчас экспериментирую с составными индексами, дело осложняется тем, что главный идентификатор - число. Попробую что-то вроде str(id)+... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2007, 11:06
|
|||
|---|---|---|---|
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
FreeLSDСортировку хотелось бы произвольную, чтобы пользователь сам устанавливал порядок, для этого создал отдельное поле. ВладимирМЕсли предполагается разнообразная сортировка или дополнительная фильтрация записей подчиненной таблицы, то лучше делать выборку по коду главной таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2007, 11:50
|
|||
|---|---|---|---|
|
|||
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
Это решение напрашивается, я б так и сделал, если бы писал форму с нуля. А так приходится переделывать, что есть, хочется обойтись "малой кровью", вот и хочу странного :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2007, 11:58
|
|||
|---|---|---|---|
|
|||
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
И можно вот так Set filter to ATC(cSearchExpression, cExpressionSearched [, nOccurrence]) > 0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2007, 12:32
|
|||
|---|---|---|---|
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
FreeLSDЭто решение напрашивается, я б так и сделал, если бы писал форму с нуля. А так приходится переделывать, что есть, хочется обойтись "малой кровью", вот и хочу странного :) Форму надо бы порвать на две: встал на нужную организацию, нажал кнопку просмотр, открылась вторая форма, сделалась выборка в курсор и крути его как хочешь. На одной форме два грида лучше по relation иначе при каждом переходе надо новую выборку делать - тормоза при поиске нужной организации. Как вариант частичного решения проблемы, если данные сильно не меняются отсортировать физически телефоны в нужном (наиболее часто требуемом) порядке. Только эту сортировку периодически обновлять надо. Т.к. при использовании индекса по ParentId в дочерней таблице записи идут в том порядке, в котором они в DBF записаны. Вариант с кучей индексов типа str(id)+... тоже не самый лучший. В случае спецполя - тормоза будут при его заполнении, т.к. при этом индекс будет перестраиваться. И где гарантия что два пользователя одновременно не захотят одну организацию посмотреть? Рекомендую подумать о курсорах (VIEW с параметром например) и заполнении второго грида по нажатию кнопки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2007, 12:43
|
|||
|---|---|---|---|
|
|||
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
Dima T Форму надо бы порвать на две: встал на нужную организацию, нажал кнопку просмотр, открылась вторая форма, Так оно и есть, только во второй форме грид берет записи прямо из таблицы, без предварительной выборки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2007, 12:51
|
|||
|---|---|---|---|
Сортировка в GRID - один индекс поверх другого? |
|||
|
#18+
FreeLSD Dima T Форму надо бы порвать на две: встал на нужную организацию, нажал кнопку просмотр, открылась вторая форма, Так оно и есть, только во второй форме грид берет записи прямо из таблицы, без предварительной выборки. Замени таблицу на обновляемое параметризированное Local View или CursorAdapter. Модификация минимальная (можно добавить прямо в DataEnvironment), но "руки уже развязаны" в смысле дополнительной сортировки и фильтрации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=41&mobile=1&tid=1588792]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 390ms |
| 0 / 0 |
