【问题标题】:Oracle: column ambiguously definedOracle:列定义不明确
【发布时间】:2011-11-07 10:36:04
【问题描述】:

我知道有很多这样的问题,但我的问题不是如何摆脱这个错误,而是要知道它在早期的 9 版 Oracle 中是如何工作的。

我有一个用 Ruby 和 Oracle DB 编写的旧资源,最近升级到 version=11。

我无法编辑 Oracle DB 中的数据,只能读取。所以有两个表可以说:表 A(id, name, type, customer) 和表 B(id,a_id,type,person)

所以。源码中有查询:

select a.id,b.id from a join b on a.id = b.a_id where type = 'A'

所以在 Oracle 9 中这工作得很好,但现在我遇到了“列不明确定义”错误。

我想知道的是:

where type = 'A'

一样
where a.type = 'A' AND b.type = 'A'

where a.type = 'A' OR b.type = 'A'

?

【问题讨论】:

  • 我真的很惊讶它在 Oracle 9 中工作。那个查询应该从来没有工作过。
  • 您不是在迁移到 Oracle 11 的同一过程中将 TYPE 列添加到其中一个表中吗?或者,也许 GRANT 使您可以看到其中一列?
  • 实际上我无法回答这个问题,因为我不是 DBA。所以我只是不知道这个数据库是如何迁移的(
  • 所以我询问了 DBA 并获得了该信息:旧 DB 版本 10.2.0.4.0 - 查询运行良好新 DB 版本 11.2.0.2.0 - 我收到错误
  • 请添加两个表的真实ddl,以及真实的查询

标签: oracle join defined


【解决方案1】:

不,这就是问题所在:这可能意味着

where a.type = 'A'

或者它可能意味着

where b.type = 'A'

可能会产生不同的结果;因此错误说它的定义不明确。

【讨论】:

  • 是的,我知道。但在 oracle 9 中没有这样的错误......所以它以某种方式工作并返回了结果。所以现在为了避免这个错误,我必须修改查询,但我不明白它之前是如何工作的。
  • @Andrey:在 Oracle 9 中测试模棱两可的查询(你说它工作的地方)并检查输出以查看它使用的两个中的哪一个:where a.type = 'A'where b.type = 'A'
【解决方案2】:

我认为您应该在 Oracle 9 中进行测试(您说它可以工作)并比较模棱两可的查询的输出:

--- Base
select a.id,b.id from a join b on a.id = b.a_id where type = 'A'

两个明确的:

--- QueryA
select a.id,b.id from a join b on a.id = b.a_id where a.type = 'A'

和:

--- QueryB
select a.id,b.id from a join b on a.id = b.a_id where b.type = 'A'

这样的事情会做:

select a.id,b.id from a join b on a.id = b.a_id where type = 'A'
MINUS
select a.id,b.id from a join b on a.id = b.a_id where a.type = 'A'

(简而言之):

(Base)
MINUS
(QueryA)

然后:

(QueryA)
MINUS
(Base)

如果上述两个MINUS 查询都返回 0 行,则 BASE 查询被解释为 QueryA。

类似地检查并将 Base 与 QueryB 进行比较。


此错误的另一个可能原因是在迁移期间(或大约在同一时期),在第二个表中添加了 type 列。你有旧版本的数据库表定义来检查吗?

【讨论】:

    【解决方案3】:

    我认为这是 ANSI 样式连接的错误。使用 DBMS_XPLAN 查找旧数据库中正在过滤的表。

    或者更好的是,从业务逻辑中找出他们查询的应该是什么。

    【讨论】:

    • 所以。谢谢大家的帮助。所以我终于找到了很久以前写这个查询的人,他向我解释了查询的逻辑。
    【解决方案4】:

    所有 - 请记住,11g 的优化引擎发生了重大变化。如果您在 11g 实例上将查询优化器级别设置为 10.2.x,我敢打赌,查询将再次开始工作。

    话虽如此,您应该为其提供别名,这样数据库服务器或后面的 DBA / 开发人员就不会模棱两可了。 :)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-10-20
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多