Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2008.03.23;
Скачать: CL | DM;

Вниз

Не выполняется SQL   Найти похожие ветки 

 
DelphiN! ©   (2008-02-22 07:10) [0]

Написал SQL :


SELECT DISTINCT(CAST(TIME_ AS DATE)) DATA,SUM(SUMM_) TEKUSHAYA_SUMMA,

(SELECT SUM(SUMM_) FROM CASEBASE WHERE (TIME_ > MAIN.TIME_-7)and(TIME_ < MAIN.TIME_)
and(prim_ <> "Login activated")and (prim_ <> "Login deactivated"))
Summa_za_poshliy_period

FROM CaseBase MAIN WHERE (TIME_ > "13.08.2007")and(TIME_ < "14.10.2007")
and (prim_ <> "Login activated") and (prim_ <> "Login deactivated")
GROUP BY 1
ORDER BY 1


Однако при попытке выполнения FireBird возвращает мне ошибку :

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).


Если я убираю условия выделенные жирным, запрос выполняется без ошибок, в чем моя ошибка?

Dialect 3


 
ЮЮ ©   (2008-02-22 08:23) [1]

1) отформатируй
2) если есть GROUP BY, то только агрегатнее функции и поля, перечисленные в GROUP BY

З.Ы. Сосояние не позволяет врубится в смысл запроса, написанного в таком стиле.


 
Sergey13 ©   (2008-02-22 09:00) [2]

> [0] DelphiN! ©   (22.02.08 07:10)
> в чем моя ошибка?

В том, что нахватавшись верхов, ты не понимаешь смысла того, что пишешь.
DISTINCT, GROUP BY - как по твоему это должно сочетаться? Твой подзапрос - это агрегат или поле по которому надо агрегировать?


 
DelphiN!   (2008-02-22 09:01) [3]


> Sergey13 ©   (22.02.08 09:00) [2]



SELECT DISTINCT(CAST(TIME_ AS DATE)) DATA,SUM(SUMM_) TEKUSHAYA_SUMMA,

(SELECT SUM(SUMM_) FROM CASEBASE WHERE (TIME_ > MAIN.TIME_-7)and(TIME_ < MAIN.TIME_)
and(prim_ <> "Login activated")and (prim_ <> "Login deactivated"))
Summa_za_poshliy_period

FROM CaseBase MAIN WHERE (TIME_ > "13.08.2007")and(TIME_ < "14.10.2007")
and (prim_ <> "Login activated") and (prim_ <> "Login deactivated")
GROUP BY 1,TIME_
ORDER BY 1


Так будет верно?


 
Sergey13 ©   (2008-02-22 09:22) [4]

> [3] DelphiN!   (22.02.08 09:01)

> Так будет верно?

Ты на кофейной гуще гадаешь? Запусти да проверь. Мой прогноз - не верно.


 
DelphiN!   (2008-02-22 09:26) [5]

Действительно, запрос не выводит уникальные даты в 1ом поле:(

А как тогда добавить в GROUP BY поле TIME_ чтобы его можно было использовать в под запросе и одновременно оставить группировку по первому полю?


 
Sergey13 ©   (2008-02-22 09:47) [6]

> [5] DelphiN!   (22.02.08 09:26)
> А как тогда добавить в GROUP BY поле TIME_ чтобы его можно
> было использовать в под запросе и одновременно оставить
> группировку по первому полю?

А "по первому полю" и "поле TIME_" это по разным полям?
DISTINCT тебе зачем?


 
DelphiN!   (2008-02-22 10:42) [7]


> Sergey13 ©   (22.02.08 09:47) [6]


Первое поле это представление поля TIME_ как DATE. На самом деле поле TIME_ хранится в базе как TIMESTAMP.
 В таком случае почему FireBird не даёт мне использовать поле TIME_ в под запросе?


 
DelphiN!   (2008-02-22 10:48) [8]

Вообще смысл запроса таков :

Есть база данных с выручкой, в базе данных значения в поле TIME_ хранятся в виде 01.01.2008 13:02:01 мне необходимо вывести

в первом столбце - дату,
во втором - выручку за эту дату*,
а в третьем - выручку недельной давности от даты в 1ом столбце

* Выручка за дату 02.01.2008 это промежуток с 02.01.2008 00:00:00 - 02.01.2008 23:59:59

Тоесть в результате таблица должны выглядеть следующим образом :

01.02.2008    50 000  60 000
02.02.2008    80 000  40 000
...............    ........   .........


 
www   (2008-02-22 10:51) [9]


> za_poshliy_period

оно!


 
Johnmen ©   (2008-02-22 11:15) [10]


> поле TIME_ хранится в базе как TIMESTAMP

>  в базе данных значения в поле TIME_ хранятся в виде 01.
> 01.2008 13:02:01

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


 
Sergey13 ©   (2008-02-22 11:22) [11]

> [8] DelphiN!   (22.02.08 10:48)
> в первом столбце - дату,
> во втором - выручку за эту дату*,
> а в третьем - выручку недельной давности от даты в 1ом столбце

Первые 2 столбца вопросов ен вызывают. Но вот третий выходит за границы моего воображения - что-то я не могу придумать для чего это.


 
DelphiN!   (2008-02-22 11:24) [12]


> Johnmen ©   (22.02.08 11:15) [10]


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


 
DelphiN!   (2008-02-22 11:27) [13]


> Sergey13 ©   (22.02.08 11:22) [11]


(SELECT SUM(SUMM_) FROM CASEBASE WHERE (TIME_ > MAIN.TIME_-7)and(TIME_ < MAIN.TIME_))
Summa_za_poshliy_period

Выборка за период :
С     дата из 1го столбца минус 7 дней      по       дата из первого столбца


 
DelphiN!   (2008-02-22 11:30) [14]


> Sergey13 ©   (22.02.08 11:22) [11]


Это нужно для сравнения выручки за текущую неделю с выручкой за прошлую


 
Виталий Панасенко(дом)   (2008-02-22 11:45) [15]

Не проще ли ХП написать ? Хотя...


 
Правильный_Вася   (2008-02-22 11:45) [16]


> Это нужно для сравнения выручки за текущую неделю с выручкой
> за прошлую

если какой-то день пропущен в текущей неделе (выходной например), означает ли это, что в прошлой его тоже не было?
это к вопросу логики запроса


 
sniknik ©   (2008-02-22 11:47) [17]

> то нужно для сравнения выручки за текущую неделю с выручкой за прошлую
> ...
> Тоесть в результате таблица должны выглядеть следующим образом :
ну и сделай 2 выборки (можно в подзапросах) с объединением их по полю группировки (дате. в одном из -7...)
если конечно синтаксис в FB позволяет 2 подзапроса объединять.

> Я знаю что они хранятся в числовом виде, но если я напишу дату в числовом представлении без времени и с временем,
> то не будет наглядно видно того что я хотел сказать о присутствии времени у даты
т.е. тупые мастера, у которых ты спрашиваешь совета не поймут если написать так как есть на самом деле... обязательно надо соврать чтоб им понятнее было... и показать для обсуждения запрос обязательно нужно на "виртуально-авторском sql" где действие не значит то что написано а значит то что ты под этим подразумевал (но никому не обьяснил что).
???


 
Sergey13 ©   (2008-02-22 11:51) [18]

> [14] DelphiN!   (22.02.08 11:30)
> Это нужно для сравнения выручки за текущую неделю с выручкой за прошлую
И как ты сравнишь это при предполагаемой структуре запроса?
сумма на 1    сумма с 24 по 31
сумма на 2    сумма с 25 по 1
сумма на 3    сумма с 26 по 2
сумма на 4    сумма с 27 по 3


 
DelphiN!   (2008-02-22 12:27) [19]


> Правильный_Вася   (22.02.08 11:45) [16]


Не бывает выходных, работает все 365 дней в году


> sniknik ©   (22.02.08 11:47) [17]


> ну и сделай 2 выборки (можно в подзапросах) с объединением
> их по полю группировки (дате. в одном из -7...)
> если конечно синтаксис в FB позволяет 2 подзапроса объединять.

Так я и пытался все по дате сгруппировать, но когда пишу GROUP BY 1; FireBird не дает мне использовать поле TIME_ в подзапросе

> т.е. тупые мастера, у которых ты спрашиваешь совета не поймут
> если написать так как есть на самом деле... обязательно
> надо соврать чтоб им понятнее было... и показать для обсуждения
> запрос обязательно нужно на "виртуально-авторском sql" где
> действие не значит то что написано а значит то что ты под
> этим подразумевал (но никому не обьяснил что).
> ???


FireBird при запросе select TIME_ from casebase выводит поля типа TIMESTAMP в формате dd.mm.yyyy hh:nn:ss, но на самом деле дата хранится в числовом виде, но для удобства в числовом виде она не выводится, вот в каком она выводится для человека я и написал. А SQL запрос я не коверкал, и привел его в таком виде, в котором я его выполняю в редакторе SQL кода


> Sergey13 ©   (22.02.08 11:51) [18]
>
> И как ты сравнишь это при предполагаемой структуре запроса?
>
> сумма на 1    сумма с 24 по 31
> сумма на 2    сумма с 25 по 1
> сумма на 3    сумма с 26 по 2
> сумма на 4    сумма с 27 по 3


Но ведь подзапрос должен делать именно это


(SELECT SUM(SUMM_) FROM CASEBASE WHERE (TIME_ > MAIN.TIME_-7)and(TIME_ < MAIN.TIME_))
Summa_za_poshliy_period


[сумма на 1]     [сумма > (1 - 7)    и    сумма < 1]
[сумма на 2]     [сумма > (2 - 7)    и    сумма < 2]

Для 1го числа выборка будет с 24го по 31е, тоесть ровно неделю до 1го


 
Sergey13 ©   (2008-02-22 12:37) [20]

> [19] DelphiN!   (22.02.08 12:27)
> Для 1го числа выборка будет с 24го по 31е, тоесть ровно неделю до 1го
Ну и каков смысл этих данных? Я понимаю смысл если сравнивать теущую неделю и предыдущую неделю. А за сегодня и за прошлую неделю - не понимаю. Еще было бы понятно, если бы ты агрегировал например по отелам (кассам, магазинам или что там у тебя) и хотел вывести сразу сегодняшнюю выручку и недельную. А так - мой мозг не постигает твоей задачи.

Запрос просто по дате (без недельной части) получается?


 
ANB   (2008-02-22 12:37) [21]

Повесь на подзапрос еще одну Sum() (Еще одни скобки обязательны), ругаться перестанет по Group by 1. Правда, будет ли запрос выдавать то, что тебе надо я не гарантирую


 
DelphiN!   (2008-02-22 12:47) [22]


> Sergey13 ©   (22.02.08 12:37) [20]
>
> Ну и каков смысл этих данных? Я понимаю смысл если сравнивать
> теущую неделю и предыдущую неделю. А за сегодня и за прошлую
> неделю - не понимаю.

Тьфу блин, сорри туплю ...
Нужно сравнивать именно за текущий день и за день 7ми дневной давности
тоесть

(CAST(TIME_ as DATE) > CAST(MAIN.TIME_ as DATE)-7)and(CAST(TIME_ as DATE) < CAST(MAIN.TIME_ as DATE) - 6)



> Запрос просто по дате (без недельной части) получается?


Да, получается


 
sniknik ©   (2008-02-22 12:47) [23]

> Так я и пытался все по дате сгруппировать, но когда пишу GROUP BY 1
а я вообщето говорил об ОБЪЕДИНЕНИИ двух различно сгруппированных подзапросов, а не "написать GROUP BY 1" в твой неизвестно для чего собранный в кучку набор служебных слов sql.

для начала сделай 1 (ОДИН) рабочий запрос с группировкой по дню и суммой по этому дню. 2 шаг, РАЗДЕЛЬНО т.е. независимо от первого такой же запрос с группировкой по тому же дню, но с суммированием на неделю раньше (-7). и только потом объединяй 2 разных запроса по одному общему полю - дню.
доступно?

> Для 1го числа выборка будет с 24го по 31е, тоесть ровно неделю до 1го
вообщето "с  .... и по ...." это не по дню, а за неделю (в данном случае). т.что пока не было сказано словами о цели
> Это нужно для сравнения выручки за текущую неделю с выручкой за прошлую ...
смысл данного кода был совершенно другим (почитай с позиции новых знаний ветку, и возмущения о непонимании того что ты делаешь... бо муть.)


 
sniknik ©   (2008-02-22 12:51) [24]

> тоесть
> (CAST(TIME_ as DATE) > CAST(MAIN.TIME_ as DATE)-7)and(CAST(TIME_ as DATE) < CAST(MAIN.TIME_ as DATE) - 6)
что символизирует этот "код"? по простому на словах... очередной "суповой набор из sql-ых слов"?


 
Правильный_Вася   (2008-02-22 12:59) [25]


> Не бывает выходных, работает все 365 дней в году

"не верю!"
террористы кабель порежут, тоже работать будет?


 
ANB   (2008-02-22 17:19) [26]


> террористы кабель порежут, тоже работать будет?

Могут и просто клиенты не прийти. День все равно из выборки вывалится.


 
sniknik ©   (2008-02-22 18:37) [27]

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

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


 
Правильный_Вася   (2008-02-22 20:56) [28]


> о "тонкостях" лучше не вспоминать

да, судя по реакции автора, тонкости будут восприниматься большими откровениями в процессе эксплуатации


 
DelphiN!   (2008-02-25 06:08) [29]


> sniknik ©   (22.02.08 12:51) [24]

> > (CAST(TIME_ as DATE) > CAST(MAIN.TIME_ as DATE)-7)and(CAST(TIME_
> as DATE) < CAST(MAIN.TIME_ as DATE) - 6)
> что символизирует этот "код"? по простому на словах... очередной
> "суповой набор из sql-ых слов"?


Выборка с: даты на 7 дней меньше даты из 1го столбца, по: дату на 6 дней меньше чем дата в 1ом столбце. Тоесть выборка за один день недельной давности от даты из первого столбца


> sniknik ©   (22.02.08 12:47) [23]


> для начала сделай 1 (ОДИН) рабочий запрос с группировкой
> по дню и суммой по этому дню. 2 шаг, РАЗДЕЛЬНО т.е. независимо
> от первого такой же запрос с группировкой по тому же дню,
>  но с суммированием на неделю раньше (-7). и только потом
> объединяй 2 разных запроса по одному общему полю - дню.


Отдельно запросы работают :


1.
SELECT DISTINCT(CAST(TIME_ AS DATE)),SUM(SUMM_)
FROM CaseBase MAIN WHERE (TIME_ > "13.09.2007")and(TIME_ < "14.10.2007")
and (prim_ <> "Login activated") and (prim_ <> "Login deactivated")
GROUP BY 1
ORDER BY 1


Данный запрос работает верно

2.

SELECT DISTINCT(CAST(TIME_ AS DATE)),

(SELECT SUM(SUMM_) FROM CASEBASE WHERE
(CAST(TIME_ as DATE) > CAST(MAIN.TIME_ as DATE)-7)and
(CAST(TIME_ as DATE) < CAST(MAIN.TIME_ as DATE) - 6))

FROM CASEBASE MAIN WHERE
(TIME_ > "13.09.2007")and(TIME_ < "14.10.2007")
and(prim_ <> "Login activated")and (prim_ <> "Login deactivated")
GROUP BY 1
ORDER BY 1


Этот запрос в 1ом столбце данные выводит, а во 2ом пустые значения, почему?


 
DelphiN!   (2008-02-25 07:35) [30]

Поправил 2ой запрос, теперь работает, как их теперь объединить?


SELECT DISTINCT(CAST(TIME_ AS DATE)), SUM(SUMM_),

(SELECT SUM(SUMM_) FROM CASEBASE WHERE
(TIME_ > CAST(MAIN.TIME_ as DATE) - 7)and
(TIME_ < CAST(MAIN.TIME_ as DATE) - 6))

FROM CASEBASE MAIN WHERE
(TIME_ > "13.09.2007")and(TIME_ < "14.10.2007")
and(prim_ <> "Login activated")and (prim_ <> "Login deactivated")
GROUP BY 1
ORDER BY 1


 
DelphiN!   (2008-02-25 07:37) [31]

Упс! Последний запрос это то что мне нужно! Он работает! Спасибо всем!



Страницы: 1 вся ветка

Текущий архив: 2008.03.23;
Скачать: CL | DM;

Наверх




Память: 0.56 MB
Время: 0.017 c
3-1193861534
Trump
2007-10-31 23:12
2008.03.23
Как лучше организовать базу данных для коммерческого продукта?


15-1202683406
Германн
2008-02-11 01:43
2008.03.23
Ещё один пример нестандартного мЫшления некоторых "кодеров"


2-1204033951
AlexeyMir
2008-02-26 16:52
2008.03.23
Как обозвать компонент созданный в процессе выполнения программы


2-1204008737
Рома....
2008-02-26 09:52
2008.03.23
Потоки


11-1186050008
Andrey_rus
2007-08-02 14:20
2008.03.23
Выравнивание контролов