Sql 这不是表达式的分组
首先,我使用ORM连接Oracle数据库并从中获取数据 当我从某个数据库管理工具调用存储过程时,一切正常 当我想从我的ORM运行这个时,问题就开始了。 它给出了一个错误:Sql 这不是表达式的分组,sql,oracle,group-by,orm,decode,Sql,Oracle,Group By,Orm,Decode,首先,我使用ORM连接Oracle数据库并从中获取数据 当我从某个数据库管理工具调用存储过程时,一切正常 当我想从我的ORM运行这个时,问题就开始了。 它给出了一个错误: ORA-00979:这不是表达式分组 通常情况下,它发生在未聚合或非常量数据未出现在group by子句中时 查询包含在存储过程中,所以每次我尝试运行它时,它都是相同的,并且它拥有GROUPBY子句中所需的所有内容 我甚至登录到同一个oracle用户。我也做了一些痕迹,但没有什么奇怪的 查询如下所示: for rec in
ORA-00979:这不是表达式分组
通常情况下,它发生在未聚合或非常量数据未出现在group by子句中时
查询包含在存储过程中,所以每次我尝试运行它时,它都是相同的,并且它拥有GROUPBY子句中所需的所有内容
我甚至登录到同一个oracle用户。我也做了一些痕迹,但没有什么奇怪的
查询如下所示:
for rec in (
select t1.field1,
t1.field2,
t1.field3,
t1.field4,
t1.field5,
decode(parameter,'T',nvl(t1.version, '-'),t1.version),
sum(nvl(t1.liczba2,0)) as left_to_dispatch
from table_1 t1
group by
t1.field1,
t1.field2,
t1.field3,
t1.field4,
t1.field5,
decode(parameter,'T',nvl(t1.version, '-'),t1.version))
loop
null;
end_loop;
问题是:ORM是否在数据库中(而不是在会话中)设置了任何可能导致此类错误的设置
顺便说一句,我试着将解码替换为case:我得到了相同的错误
我试图将解码替换为NVL的,我得到了相同的错误
但错误只是来自这个ORM工具,当我试图从PLSQL开发人员那里运行它时,一切正常
有什么想法吗
注:当我将查询更改为这样的查询时,ORM工作正常:
for rec in (
select t1.field1,
t1.field2,
t1.field3,
t1.field4,
t1.field5,
t1.version,
sum(nvl(t1.liczba2,0)) as left_to_dispatch
from table_1 t1
group by
t1.field1,
t1.field2,
t1.field3,
t1.field4,
t1.field5,
t1.version)
loop
null;
end_loop;
可能你忘了后面的逗号 解码(参数,'T',nvl(t1.version,'-',t1.version) 解码(参数,'T',nvl(t1.version,'-',t1.version), sum(nvl(t1.liczba2,0))是一个旧的Oracle函数,您的ORM可能无法解释它。为什么不改用
案例
?这是标准SQL,因此ORM可能更容易处理
select t1.field1,
t1.field2,
t1.field3,
t1.field4,
t1.field5,
case when parameter = 'T' then coalesce(t1.version, '-') else t1.version end,
sum(nvl(t1.liczba2,0)) as left_to_dispatch
from table_1 t1
group by
t1.field1,
t1.field2,
t1.field3,
t1.field4,
t1.field5,
case when parameter = 'T' then coalesce(t1.version, '-') else t1.version end
注意,我还用标准的SQL函数
coalesce()
替换了nvl()
。使用旧的Oracle函数没有什么错:Oracle仍然支持它们。然而,它们可以追溯到甲骨文创新SQL的速度快于ANSI委员会的时候。一般来说,第三方“数据库无关”工具使用标准SQL比使用特定于产品的SQL更有效 我怀疑您的两个decode()
语句不完全相同。我的建议是使用子查询,这样就不必重复表达式
我还更喜欢case
和coalesce()
(标准SQL构造),因此:
你的ORM工具是什么?我们可能需要知道这一点。另外,请包括您调用此查询的相关代码。进行了一些编辑。您在这里做了什么,案例也不起作用。好像是个虫子。。。我只是尝试了你们所做的,同样的情况:ORM中有错误,PLSQL开发人员中没有错误。我也对你们的答案投了赞成票,因为事实上ORM在解释group by子句中高于正常值的字段时遇到了问题。谢谢你的努力。嗯,也许真的是ORM看到这些解码的方式不同于我的眼睛和其他工具。你给了我一个好主意,我正在检查。好吧,因为毫无疑问ORM有问题,而且我想在不知道内部代码的情况下猜测可能有什么问题是毫无意义的,所以我将你的答案标记为解决问题的答案。现在查询返回与以前相同的结果,并且两种工具都在使用。谢谢你的帮助!请阅读帮助中心的答案好。。。
select t1.field1, t1.field2, t1.field3, t1.field4, t1.field5, new_version,
sum(coalesce(t1.liczba2, 0)) as left_to_dispatch
from (select t1.*
(case when parameter = 'T' then coalesce(t1.version, '-') else t1.version end) as new_version
from table_1 t1
) t1
group by t1.field1, t1.field2, t1.field3, t1.field4, t1.field5, new_version;