Сортировка по Lookup-полю

← →
Fantom_ (2003-10-08 13:13) [0]

Добрый день. Вопрос такой: как отсортировать данные в Lookup-поле не по хранимому значению, а по отображаемому в DBGridEh?
Результатом моих изысканий стало зыбкое мнение, что нужно нечто сотворить с гридом, а что именно - неясно.
Помогите пожалуйста.

← →
Johnmen (2003-10-08 13:23) [1]

Никак...

← →
Val (2003-10-08 13:29) [2]

>Johnmen © (08.10.03 13:23) [1]
не устал? ;)

← →
Fantom_ (2003-10-08 13:39) [3]

Устал. Знаю. Я так, для успокоения совести спросил.
Что делать-то?
Клиент требует порядок, а у меня в это поле значения автоинкремента из другой таблицы прописывается, естеснно данные в гриде вразброс. Неудобно.

← →
Johnmen (2003-10-08 14:01) [4]

>Val © (08.10.03 13:29)

:)

>Fantom_ (08.10.03 13:39)

Так добавь это поле в запрос. Т.е. в запросе будет соединение таблиц, основной и справочника. И в запросе же сортируй...

← →
Fantom_ (2003-10-08 14:09) [5]

Попробуем-попробуем...

← →
Fantom_ (2003-10-08 14:44) [6]

Попробовал. Работает. Так все просто оказывалось. э-э-х...
Спасибо!

← →
Vick (2003-10-08 15:55) [7]

А есть еще вариант - использовать Мидас, в Clientdataset перекачивать данные и там уже с ними делать чего угодно, кстати это касается и вычисляемых полей...

← →
Fantom_ (2003-10-14 15:06) [8]

Привет после выходных!

>
> Johnmen © (08.10.03 14:01) [4]
>
> Так добавь это поле в запрос. Т.е. в запросе будет соединение
> таблиц, основной и справочника. И в запросе же сортируй...

Рано я обрадовался. Сортировать-то запрос сортирует, внешне все прекрасно, но при попытке удаления записи движок честно и добросовестно пытается удалить запись не только в главной, но и в связанной таблице. Так, в принципе и должно быть, если бы не пара важных моментов:
А)объективно - подчиненных записей в справочнике МНОГО;
б)субъективно - удалять записи из справочника незачем.
Итог - получили ошибку. Но все равно спасибо за совет.

← →
Val (2003-10-14 15:23) [9]

>Fantom_ (14.10.03 15:06) [8]
???
так из таблицы-то запись нужно удалять, на которую запрос/просмотр опирается, а не из просмотра/НД.

← →
Fantom_ (2003-10-14 16:57) [10]

Я недавно занялся Делфи, поэтому за глупые вопросы извиняюсь - за прошлые и впредь.

> так из таблицы-то запись нужно удалять, на которую запрос/просмотр
> опирается, а не из просмотра/НД.

Поясни, пожалуйста, подробнее. Я же не с сервером работаю, а пишу клиент под него. Мне еще многое не понятно.

Смотри: бросаю я на форму ADOQwery и пишу запрос, объединяющий две таблицы - главную и справочник. Отображаются поля только главной. Но таблицы-то связаны и удаление поля в главной влечет за собой удаление в подчиненной.

← →
Val (2003-10-14 17:11) [11]

>Fantom_ (14.10.03 16:57) [10]
Тут нужны знания больше не в делфи, а в базах данных.
Вы вероятно говорите об удалении записей все-таки, а не полей.
Записи из подчиненной таблицы удаляются потому, что у вас, вероятно, соответствующим образом написано ограничение (on delete cascade) или срабатывает триггер.
Справочник, в данном случае - главная таблица, а не подчиненная, поскольку не ее записи зависят от других таблиц, а наоборот.

← →
Fantom_ (2003-10-15 09:17) [12]

Да, прошу прощения, я имел в виду удаление записей.
Не могли бы вы объяснить, по каким правилам система производит удаление записи, если запись удаляется из запроса на объединение двух таблиц - справочника, и "основной" таблицы (надеюсь, я правильно сформулировал)? Что необходимо знать об этом при разработке приложений?

Кстати, триггеров таких нет и ограничений на каскадное удаление не установлено. Может проблема в том, что с одной стороны справочник участвует в объединении, а с другой его записи используются для наполнения выпадающего списка в гриде (не Loockup поля, а именно программного наполнения) и при удалении возникает какая-то конфликтная ситуация? Я пытался это все анализировать - на мой взгляд алгоритм последовательный и безконфликтный. Но ошибка имеет место, значит я ошибся в рассуждениях.

← →
Sergey13 (2003-10-15 09:36) [13]

2Fantom_ (15.10.03 09:17) [12]
Ты бы написал конкретно свой запрос и то как удаляешь. А то

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

Так в принципе НЕ должно быть, если делать правильно. И с чего ты вообще решил, что удаляется "и в связанной таблице".

ЗЫ:Я с МССКЛ не работал, но что то мне подсказывает...

← →
Fiend (2003-10-15 09:40) [14]

у меня тоже было подобное при удалении. я так понял используется АДО?
тогда вот это вам поможет:
надо сразу после того как сделали Open для ADOQuery с тем самым запросом установить свойство
ADOQuery.Properties["Unique Table"].Value:="MyMainTable";

← →
Val (2003-10-15 09:42) [15]

>Fantom_ (15.10.03 09:17) [12]
..если запись удаляется из запроса на объединение двух таблиц..
вот об этом я и говорил - не нужно удалять запись из НД(такого объекта ведь нет в БД!), нужно удалять запись только из "основной" таблицы, где ID = ID текущей записи из НД, затем переоткрыть запрос.

← →
Fiend (2003-10-15 09:43) [16]

да, и советую почитать статью по этому поводу
http://www.delphikingdom.com/helloworld/ado03.htm

← →
Fantom_ (2003-10-15 10:11) [17]

> Sergey13 © (15.10.03 09:36) [13]

> Так в принципе НЕ должно быть, если делать правильно. И
> с чего ты вообще решил, что удаляется "и в связанной таблице".

Не спорю, уже понял. Мораль: надо сначала думать, а потом спрашивать.

> Fiend © (15.10.03 09:43) [16]

Статью читал, спасибо, она как раз лежит передо мной. Кое-что проясняет. Кстати, интересно, имеет ли значение порядок: устанавливать это свойство (или св-во "Update Resync") до или после открытия запроса?

> Val © (15.10.03 09:42) [15]

Попробую разобраться.
Я тут поэкспериментировал, кажется ошибка пропадает, если в запросе вместо
SELECT PRIHODS.*, NOMRAZMER.* FROM NOMRAZMER INNER JOIN PRIHODS ON NOMRAZMER.KODRAZMER = PRIHODS.KODRAZMER where PRIHODS.KODMAT=:kodmat
использовать
**** RIGHT JOIN ****

← →
Sergey13 (2003-10-15 10:20) [18]

2Fantom_ (15.10.03 10:11) [17]
Сори, что встрял. Я просто не в курсе и думал, что это в принципе невозможно. Но после прочтения ссылки [16] понял, что ничего невозможного не бывает. 8-)

← →
Fantom_ (2003-10-15 10:48) [19]

И все-таки она не пропала.:(

← →
Val (2003-10-15 11:04) [20]

как удаляете-то??

← →
Fantom_ (2003-10-15 11:36) [21]

Ручками. Т.е. выделяем запись в гриде, нажимаем Ctrl+del.
Никаких обработчиков я пока не писал.

P.S. Наверное мне нужно спросить: как мне правильно задать вопрос, чтобы получить ответ?

← →
Danilka (2003-10-15 11:38) [22]

[21] Fantom_ (15.10.03 11:36)
А ты вот-так: [14] Fiend © (15.10.03 09:40)
сделал?

Или хотя-бы статью: [16] Fiend © (15.10.03 09:43)
прочитал?

← →
Danilka (2003-10-15 11:40) [23]

хотя, пишешь, что статью прочитал :)

← →
Fantom_ (2003-10-15 12:18) [24]

Читал я, читал. И делал. Эффекта нет, вернее я не заметил.
Так. Давайте с самого начала и поподробнее.
Значит есть такие таблицы:
1) Prihods{ ID_Prihod,...,KodMat,KodRazmer,...}
В АДО - просто запрос на выборку по параметру, (см. [17], но без всяких объединений)
2)Nameprokat{ KodMat,namemat,}
3)NomRazmer{ KodMat,KodRazmer,Namerazmer}
Подчеркнуты ключи.
Все 3 таблицы в БД соединены.
При вставке новой записи в Prihods в зависимости от выбранного материала (Nameprokat) для поля Prihods.KodRazmer формируется список типоразмеров этого материала (NomRazmer). Естественно, в списке в гриде отображается не код типоразмера, а его наименование. Все прекрасно работает.
Теперь возникла задача: отсортировать данные для пользователя именно по наименованию типоразмера.
Была попытка объединить таблицы Prihods и NomRazmer и отсортировать по NomRazmer.Namerazmer (по совету уважаемого Johnmen [4]). Сортирует. При удалении ругается - нормально, ведь коды в NomRazmer повторяются снова для каждого материала.
Но: мне не нужно ничего удалять из NomRazmer, нужно удалить запись только в Prihods. Причем совет из ссылки [16] не действует.
И тут я как молодой и зеленый уперся лбом в стену и не знаю где ее перелезть...
Кажется все...

Сортировка по Lookup-полю Найти похожие ветки