На FB Firebird-1.5.2.4731_embed_win32 не выполняется множество запросов, которые выполнялняются на всех версиях IB.
Орет:
Invalid expression in the ORDER BY clause (not contained in either an aggregate function or the GROUP BY clause)
Пример SQL запроса:
select Count(ID), SeniorID from Classes Group By SeniorID Order By Name
Order By
Модераторы: kdv, Alexey Kovyazin
-
Ivan_Pisarevsky
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Нельзя указывать в ордер бай те поля которых нет в груп бай
select Count(ID), SeniorID from Classes Group By SeniorID Order By 2
Я так все такие запросы перелопатил когда портировал свои программы с ИБ60 на ФБ 152.
Напиши, например так:select Count(ID), SeniorID from Classes Group By SeniorID Order By Name
select Count(ID), SeniorID from Classes Group By SeniorID Order By 2
Я так все такие запросы перелопатил когда портировал свои программы с ИБ60 на ФБ 152.
Код: Выделить всё
select Count(ID), SeniorID from Classes Group By SeniorID Order By 2
Плохо что совместимости уже нет на уровне выполнения запросов а не различных фич появившихся в IB или FB.
Писать прогу совместимую с обоими серверами слишком сложно. А согласиться на прокачку данных не нужных полей для IB не хочется.
Дык баги - они на тои баги, чтобы их правили._so_ писал(а): Плохо что совместимости уже нет на уровне выполнения запросов а не различных фич появившихся в IB или FB.
Код: Выделить всё
SeniorID Name
1 AAAA
1 BBBB
1 CCCC
бага. Вот тебе еще один результат запроса:
теперь ответь мне, по какому столбцу сделан order by.
то есть
select id, fio
from persons
order by ....
кроме того, см. пример кривого запроса в
http://www.ibase.ru/ibo/n7.htm
от 27.08.2001.
Код: Выделить всё
1 Иванов В.И.
2 Петров И.П.
5 Шумилина В.Л.
3 Афанасьев Р.С.
то есть
select id, fio
from persons
order by ....
кроме того, см. пример кривого запроса в
http://www.ibase.ru/ibo/n7.htm
от 27.08.2001.
Этот пример вообще не корректен, где здесь group By. Можно определить только по другим даным.
Да я понял в что вы имеете ввиду.
Для начального запроса если есть записи с одинаковым SeniorID и разными Name, то непонятно как сортировать. Я бы таких глупых запросов и не написал.
Может мой пример не удачный.
В изначльном запросе в Group By попадало поле уникальный ключ и соотвествено поля сортировки не могли быть разные для данной групировки и это прекрасно работало. Тащить лишние даные тоже не хочется. Я понимаю что эта защита, но хотелось бы опционально если сделал, то сам дурак.
Да я понял в что вы имеете ввиду.
Для начального запроса если есть записи с одинаковым SeniorID и разными Name, то непонятно как сортировать. Я бы таких глупых запросов и не написал.
Может мой пример не удачный.
В изначльном запросе в Group By попадало поле уникальный ключ и соотвествено поля сортировки не могли быть разные для данной групировки и это прекрасно работало. Тащить лишние даные тоже не хочется. Я понимаю что эта защита, но хотелось бы опционально если сделал, то сам дурак.
Вот более правильный пример:
Особено не хочется тащить name в котором сидят строки и мне ненужна эта информация, а важен порядок.
Код: Выделить всё
select Count(ID), C1.SeniorID from Classes C1
join Classes C2 on C2.ID=C1.SeniorID
Group By C1.SeniorID
Order By C2.Name
Где ID первичный ключ.
Да ёксель-моксель, это ты знаешь, что на этих конкретных данных так можно. А серверу откуда? Сначала все записи пребрать и удостовериться, что к ним такой синтаксис применим, а к соседнему запросу - нет, фигня получится? Группировка-сортировка - это универсальные алгоритмы, которые либо должны гарантированно работать на любых данных, либо отказываться работать вообще.
Проверь на своих данных. Зависит от длины Name. И заодно ответь на вопрос (себе) - зачем в этом конкретном случае сортировка по неизвлекаемому полю. Я знаю случаи, когда она нужна в запросах обычного вида, но не могу припомнить именно для таких, как правило внутренних, не показываемых пользователю, запросов с агрегатами._so_ писал(а):А вот здесь действительно я ошибся насчетТогда такой вопрос на сколько замедлиться выполние запроса если я добавлю C2.Name в секцию Group ByОсобено не хочется тащить name в котором сидят строки и мне ненужна эта информация, а важен порядок.
Нужна и еще как нужна.И заодно ответь на вопрос (себе) - зачем в этом конкретном случае сортировка по неизвлекаемому полю.
Замедлится - это очень плохо.
Пресекать можно было бы более правильно. В моем примере 2 по структуре данных можно было бы определить что охинеи не будет (Есть первичный ключ)
Отключение возможности,а не более грамотная проработка - это не решении проблемы.
Ок спасибо за информацию.
секундочку. а нафига мне group by? мсье, давайте вести толковище оперируя понятиями вроде "множество". На диске есть исходное множество (со столбцами x, y, z). Мы его группируем, получаем другое множество (со столбцами a, b, c, замечу). Теперь к этому множеству (другому) применяем правило "отсортировать элементы множества по" по.... по какому столбцу, позвольте спросить? по столбцу z? с какого рожна?Этот пример вообще не корректен, где здесь group By. Можно определить только по другим даным.
кстати, ответ в моей загадке прост. запрос выводит результат с order by birthdate. То есть, мы тупо смотрим в результат, и нифига не понимаем, что хотел сказать разработчик программы, и почему записи отсортированы именно в таком порядке. "мы" - это пользователь программы, который исходного запроса не видит, и sql не знает.
Группировка, тем более, это порождение множества "виртуальных" записей, так или иначе агрегированных. если мы получаем в результате группировки столбцы a, b и c, то как мы вообще можем отсортировать это множество, если в нем нет столбца z?
Я вот, как и Merlin, могу припомнить случай сортировки по неизвлекаемому например такой:
Код: Выделить всё
select id, fio
from table
order by fio_upperИзвини меня, но я все равно в общем случае буду считать сортировку по невыбираемому столбцу натуральной ахинеей. просто потому, что из конечного набора записей невозможно понять, почему он выведен именно в таком порядке, а не в другом.
Малость горячишься. Есть такой класс систем - внутрикопоративные, т.е. для посвящённых в некое тотемическое знание. У меня например, список ценовых групп выводится в сортировке 'Класс товара, Наименование группы'. Какой товар к какому классу относится они и во сне ответят, название не нужно им, а вот видеть в известной степени взаимозаменяемое рядушком - удобно. Но вот агрегат, сгруппированный по одному полю, а отсортированный по другому... На ранних этапах обучения каждый из моих орлов нагородил малость такого в ХП, чиста по инерции от клиентских запросов, при помощи copy/paste например. Потом спрашиваешь - а на хрена? - Нуу... так как-то привычнее...kdv писал(а): Извини меня, но я все равно в общем случае буду считать сортировку по невыбираемому столбцу натуральной ахинеей. просто потому, что из конечного набора записей невозможно понять, почему он выведен именно в таком порядке, а не в другом.
Резюмирую. То, как сделано в IB - слишком неправильно. То, как сделано в FB - слишком правильно. Истина, как всегда, где-то посередине. Мы выбрали то, что четко предписано стандартом. Здравый смысл подсказывает, что в случае группировки по PK можно допускать сортировку по полю той же таблицы. Но проверять это в сервере - гемор. Возможно, когда-нибудь Арно начнет пить пиво и я его на это склоню Ну а пока живите с тем, что есть.
Насчет "отняли фичу" - в сад. В FB2 мы еще больше чего поотнимали. И будем продолжать в том же духе, на благо наших неразумных юзверей. Аминь.
Ну а пока живите с тем, что есть.Насчет "отняли фичу" - в сад. В FB2 мы еще больше чего поотнимали. И будем продолжать в том же духе, на благо наших неразумных юзверей. Аминь.
