Не работает ORDER BY

← →
oleg_p (2005-09-12 08:31) [0]

При выполнении запроса
SELECT PROPERTY.ID_ABS, PROP_DSC.NAME, PROP_DSC.CODE, PROP_DSC.VALUE_TYPE, PROP_DSC.POINTER_TYPE, PROP_DSC.LIST, PROPERTY.PROP_DATA, PROP_DATA_F.DATA AS DATA_F, PROP_DATA_I.DATA AS DATA_I, PROP_DATA_S.DATA AS DATA_S FROM PROP_DSC, PROPERTY LEFT OUTER JOIN PROP_DATA_F ON PROP_DATA_F.ID=PROPERTY.PROP_DATA LEFT OUTER JOIN PROP_DATA_I ON PROP_DATA_I.ID=PROPERTY.PROP_DATA LEFT OUTER JOIN PROP_DATA_S ON PROP_DATA_S.ID=PROPERTY.PROP_DATA WHERE PROP_DSC.ID=PROPERTY.PROP_DSC AND PROPERTY.ID_OBJ=:ID_OBJ AND PROP_DSC.IS_GROUP="F" AND PROP_DSC.PARENT=:PARENT ORDER BY PROP_DSC.ORD

таблица оказывается отсортированной не по PROP_DSC.ORD,
а по первичному индексу таблицы PROP_DSC. Если убрать все OUTER JOIN - сортировка идет нормально.

← →
ANB © (2005-09-12 09:15) [1]

Не могет такого быть. Значит order by отвалился при формировании запроса. Чем выполняешь ?

← →
Savek (2005-09-12 09:16) [2]

Попробуй вставить PROP_DSC.ORD в список полей Select

← →
oleg_p (2005-09-12 09:39) [3]

> Не могет такого быть. Значит order by отвалился при формировании запроса. Чем выполняешь ?

В IBDataSet.SelectSQL. Также пробовал в IBExpert - результат тот же.

> Попробуй вставить PROP_DSC.ORD в список полей Select
Уже пробовал - не помогает.

← →
Sergey13 © (2005-09-12 09:44) [4]

А если попробовать Жар птицу?

← →
oleg_p (2005-09-12 09:57) [5]

>А если попробовать Жар птицу?

Так на ней и работаю - Firebird 1.0.2. Надо конечно попробовать чё-нидь ещё ... попробую ib 6.0 поставить.

← →
ANB © (2005-09-12 10:02) [6]

> oleg_p (12.09.05 09:57) [5]
- значит либо версия кривая, либо стоит криво. Стандарт SQL обязывает твою конструкцию работать.

← →
Sergey13 © (2005-09-12 10:12) [7]

2 [5] oleg_p (12.09.05 09:57)
>Так на ней и работаю - Firebird 1.0.2.
Тогда попробуй поставить помоложе.

← →
oleg_p (2005-09-12 10:38) [8]

Поставил IB 6.5 на другой машине, переписал туда базу. Попробовал тот же запрос сначала в IBExpert удаленно через сеть, потом в IBConsole локально. Абсолютно тот же результат.

Сортировка идет либо по полю PROPERTY.ID_ABS либо по полю PROP_DSC.ID - они оба по сортировке дают один результат,поэтому точно не скажу. Оба поля в PRRIMARY KEY.

Может план запроса натолкнет на мысль:
PLAN MERGE ( SORT (PROP_DSC ORDER PROP_DSC_IDX1), SORT (JOIN (JOIN (JOIN (PROPERTY NATURAL,PROP_DATA_F INDEX (RDB$PRIMARY38)),PROP_DATA_I INDEX (RDB$PRIMARY43)),PROP_DATA_S INDEX (RDB$PRIMARY45))))

← →
Stakan © (2005-09-12 10:46) [9]

Когда-то сталкивался с такой ошибкой. Помогло создание индекса по полю в order by

← →
oleg_p (2005-09-12 10:46) [10]

... PROP_DSC_IDX1 - это индекс на поле PROP_DSC.ORD

← →
Prohodil Mimo © (2005-09-12 10:54) [11]

A jesli v kachestve imjon polej ne ispol"zovat" zarezervirovannije slova?

← →
oleg_p (2005-09-12 11:03) [12]

> Prohodil Mimo © (12.09.05 10:54) [11]
Так их там вроде и нет ???

← →
oleg_p (2005-09-12 11:20) [13]

Удалил индекс по полю PROP_DSC.ORD - ВСЕ ЗАРАБОТАЛО !!
Создаю индекс заново - опять не сортирует.
Придется пожить без индекса :-(

← →
Desdechado © (2005-09-12 11:45) [14]

вообще-то сортировка по полю, отсутствующему в SELECT, - очень дурной тон
большинство серверов обрабатывают это по-своему, если вообще обрабатывают

← →
Fay © (2005-09-12 12:41) [15]

2 Desdechado © (12.09.05 11:45) [14]
>> сортировка по полю, отсутствующему в SELECT, - очень дурной тон

Бред

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

2 Desdechado © (12.09.05 13:12) [16]
Представь себе, что мне интересно в каком порядке происходили некие события, но совершенно наплевать когда именно.

+ дополню
Дурной тон это:
... FROM PROP_DSC, PROPERTY LEFT OUTER JOIN ...
переведи объединение PROP_DSC и PROPERTY в inner join, а то как-то нехорошо получается.
... FROM PROP_DSC INNER JOIN PROPERTY ON PROP_DSC.ID=PROPERTY.PROP_DSC LEFT OUTER JOIN PROP_DATA_F ON PROP_DATA_F.ID=PROPERTY.PROP_DATA LEFT OUTER JOIN PROP_DATA_I ON PROP_DATA_I.ID=PROPERTY.PROP_DATA LEFT OUTER JOIN PROP_DATA_S ON PROP_DATA_S.ID=PROPERTY.PROP_DATA ...

← →
oleg_p (2005-09-13 08:01) [19]

Во-первых, спасибо всем за помощь.

> Desdechado © (12.09.05 13:12) [16]
Поле ORD сделано специально для сортировки,чтобы иметь возможность поменять местами две соседние записи просто обменявшись значениями ORD (Fay [17] верно сказал). При этом знать, что в нём содержится пользователю не надо вообще.

> Deniz © (13.09.05 07:33) [18]
> переведи объединение PROP_DSC и PROPERTY в inner join, а то как-то нехорошо получается.

Нехорошо, в смысле код некрасивый? Или есть более объективные причины?

Deniz © (13.09.05 07:33) [18]
А вот использование OUTER JOIN - вполне нормальное явление. Для того оно и придумано в языке, чтоб даже отсутствующие в другой таблице данные использовать, что INNER JOIN не позволяет.

>Desdechado © (13.09.05 11:43) [20]
Спасибо, конечно, за консультацию, но все это я давно знаю.
Про OUTER JOIN я ничего не говорил.
Ты меня как-то не так понял. Я имел ввиду что, в одном select"е использовать явные и неявные объединения таблиц не есть гуд и привел пример как это должно выглядеть с inner join.

>oleg_p (13.09.05 08:01) [19]
>Нехорошо, в смысле код некрасивый? Или есть более объективные причины?

Во-первых: есть вероятность, что в последствии ты забудешь прописать в where условие объединения, и результат окажется неверный.
Во-вторых: такой подход усложняет жизнь оптимизатору.
И в-последних: если память не изменяет, то в FireBird 2, такой код будет выдавать предупреждение или ошибку.

2 Deniz © (14.09.05 6:25) [21]
Не понимаю, как можно испортить жизнь оптимизатору, который годами путает left join и inner join.

Не работает ORDER BY Найти похожие ветки