iBase.ru Forum

Hi ALL.
Есть проблема с составление запроса. Ниже приведен запрос, который я писал для MySQL.
----
select
clients.name as client_name,
clients.firm as firm,
sum(cost) as summary
from
stat, clients
where
clients.id = stat.id_client
group by
id_client
order by firm, name
---

Он считает сумму по клиентам, используя группировку по идентификатору клиента (id_client). В результате он выдает сумму, имя клиента и фирму.

При переходе на Firebird 1.5 данный запрос не работает. И никак не могу сделать аналогичную вещь, скоро матом буду крыть IB.

Вот ошибка:

Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Invalid expression in the select list (not contained in either an aggregate function or the GROUP BY clause).

Очень прошу помочь.
Заранее благодарю за ответы.

совершенно верно матерится, group by должен быть по выбираемым неагрегированным столбцам. Т.е. данный запрос неверен абсолютно, и это проблема MySQL.
Надо так:
кстати - зачем лепить as для столбцов, кому это надо? в гриде все равно русские имена столбцов надо менять, хоть у TField.DisplayName, хоть в самом столбце грида.

чтобы ускорить, если name+firm всегда уникально, можно написать кстати. чей столбец cost? нехорошо неуказывать алиас таблицы при джойне более двух столбцов. мало ли, вдруг и у clients такой столбец окажется.

kdv писал(а): Надо так:

Код: Выделить всё

select c.name, c.firm, sum(cost)
from stat s, clients c
where c.id = s.id_client
group by c.name, c.firm
order by firm, name

...

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

В ордер бу их не указывать тоже нехорошо

kdv писал(а):кстати - зачем лепить as для столбцов, кому это надо?

Это надо когда выбирается несколько полей с одинаковыми именами. Если не сделать as то получатся какие-нибудь name, name2, name3 что иногда очень сильно мешает т.к. порядок нумерации не стабилен при изменении запроса.

Кстати, по русским именам - в FB сработает и такое:

Всем спасибо, помогло.
Видно MySQL более неприхотлив к конструкции select'а

раньше IB/FB тоже всякую гадость кушал. теперь стал более разборчив. это же все зависит от парсера - парсер может допускать некорректные конструкции SQL. Соответственно ядро будет выдавать неизвестно какой результат.

посмотри http://www.ibase.ru/ibo/n7.htm от 27.08.2001, там пример есть. это только один случай, а их масса.