|
|
Регистрация | << Правила форума >> | FAQ | Пользователи | Календарь | Поиск | Сообщения за сегодня | Все разделы прочитаны |
|
Опции темы | Поиск в этой теме | Опции просмотра |
#1
|
||||
|
||||
Сортировка в Lookup-поле
Всем привет!
Уже много лет не могу найти ответ на довольно важный вопрос... Я разработал несколько файл-серверных БД (таблицы формата MSAccess), и в каждом проекте возникает необходимость в сортировке Lookup-полей. Сортировка, конечно, работает, но сортирует она по коду записи в справочной таблице, а мне нужно, чтобы сортировка шла по текстовому полю "Наименование" из этой справочной таблицы. Например, у меня есть таблица "Технические параметры", одно из полей которой - ссылочное "Единицы измерения". Мне нужна сортировка по наименованию единицы измерения, а не по коду записи, вот в чём вопрос. Конечно, я придумал способ, как это сделать, но он сильно корявый: в "основную" таблицу, содержащую Lookup-поле, вводится дополнительное текстовое поле, в котором по Post сохраняется интересующее нас текстовое значение из справочной таблицы, а при попытке сортировки по данному полю идёт подмена для осуществления сортировки с задействованием данных скрытого дополнительного поля. Решение совершенно не изящное, т.к. приводит к ненужному дублированию данных, и, кроме того, необходимо периодически выполнять процедуру обновления упомянутых текстовых сортировочных данных, дабы они были актуальны. И вот вопрос - а может я дурак и просто не знаю очевидного, простого решения данного вопроса? Ведь ситуация, по-моему, очень распространённая, когда хочется сортировать не по коду записи, а по отображаемым в лукап-столбце данным... Может есть таки решение? |
#2
|
|||
|
|||
сортировать на уровне запроса.
Код:
select m.f1, m.f2, m.f3, r.f1, r.f2 from main_table m left join ref_table r on m.f3=r.f1 order by r.f2 Код:
select foo.* from ( select m.f1, m.f2, m.f3, r.f1, r.f2 from main_table m left join ref_table r on m.f3=r.f1 order by r.f2 ) foo |
Этот пользователь сказал Спасибо lmikle за это полезное сообщение: | ||
Guaho (13.09.2017)
|
#3
|
||||
|
||||
Агаааа... Вот оно чё! Совершенно не приходила в голову такая идея - сортировать на уровне запроса. Надо попробовать! Огромное спасибо за подсказку!
|
#4
|
||||
|
||||
Попробовал я этот способ. Не сразу придумал, как прицепиться к дополнительно появившемуся в НД полю, как отобразить его в гриде... Но придумал. И глазам не поверил - сортирует должным образом! НО есть один огромный минус, который перечёркивает всё: датасет почему-то стал Read Only, хотя свойство Request Live установлено в true (использую движок Absolute DataBase и его компонент TABSQuery). В то время как простой запрос вида "SELECT... ORDER BY" остаётся "живым", т.е. с редактируемыми данными. Я никогда раньше не работал с оператором JOIN, и подозреваю, что именно его использование и приводит к "омертвлению" запроса (а больше и подумать не на что). Печально... Придётся наверно старую тему городить с подменой полей...
UPD: А вот и ответ, нашёл в хелпе: "TABSQuery can return live result for single-table query only". Так что задуманное в моём случае не получится... Но в любом случае спасибо, информация полезная на будущее! Последний раз редактировалось Guaho, 27.09.2017 в 22:14. |
#5
|
|||
|
|||
Ну так всегда есть обходной маневр.
Создай updatable view с join'ом в базе и выбирай данные из нее. Тогда для твоего компонента это будет выглядеть как запрос из одной таблицы (ну если он не слишком умный и не разберется, что это вью, хотя и там можно подумать как его обмануть). зы. updatable view обычно делается путем написания триггеров на insert, update, delete для вью, которые, собтвенно, и "раскладывают" данные по нужным таблицам. |
Этот пользователь сказал Спасибо lmikle за это полезное сообщение: | ||
Guaho (27.09.2017)
|
#6
|
||||
|
||||
Спасибо за подсказку! Но увы, похоже, это не мой метод. Искал только что в хелпе строку "updatable" и ей подобные сочетания - нет ничего... Эта ABS, как я понимаю, довольно простая штука, и, видимо, список поддерживаемых операторов SQL у неё не столь велик, как хотелось бы.
|
#7
|
|||
|
|||
Еще раз. Updateble views - это ANSI термин. Т.е. тебе надо проверить следующее:
1. Есть ли возможность создавать вью. 2. Можно ли для этих вью создавать триггеры на вставку, обновление и удаление 3. Проверть, что после этого в эту вью можно вставлять/редактировать/удалять. Последний пункт просто для двойной проверки. По сути, все это проверяется за 5 минут. Делаем пару табличек. Поверх них создаем вью с join. Теперь создаем триггеры на эту вью с соответсвующим "распихиванием" колонок по таблицам. Ну и пишем пару запросиков для проверки как оно работает. |
Этот пользователь сказал Спасибо lmikle за это полезное сообщение: | ||
Guaho (28.09.2017)
|
#8
|
||||
|
||||
Технология в целом понятна, только вот не ясно, где искать Updateble? Если эта штука относится к СУБД, то такого в AbsoluteDatabase я не нашёл. А если нет, то где его искать? Я совершенно без понятия, я даже этот термин слышу впервые.
|
#9
|
|||
|
|||
Оно просто так называется.
Как создать такое вью - см выше. |