Oracle 数据库 10g 和 11g 中 select for update of ... 的差异
我发现 Oracle 数据库 10g 和 11g 对以下 PL/SQL 块的处理方式不同(为了方便起见,我使用 scott 模式):
DECLARE
v_ename bonus.ename%TYPE;
BEGIN
SELECT b.ename
INTO v_ename
FROM bonus b
JOIN emp e ON b.ename = e.ename
JOIN dept d ON d.deptno = e.deptno
WHERE b.ename = 'Scott'
FOR UPDATE OF b.ename;
END;
/
在 10g (10.2) 中,此代码成功结束(引发 NO_DATA_FOUND 异常,但这是预期的),在11g (11.2) 它引发异常“列定义不明确”。这绝对不是我们所期望的。似乎它没有考虑表别名,因为我发现当我将 FOR UPDATE OF e.empno 中的列(也不起作用)更改为 e.mgr(这是独一无二的)它开始工作。那么这是 11g 中的一些错误吗?有什么想法吗?
I found out that Oracle Database 10g and 11g treat the following PL/SQL block differently (I am using scott schema for convenience):
DECLARE
v_ename bonus.ename%TYPE;
BEGIN
SELECT b.ename
INTO v_ename
FROM bonus b
JOIN emp e ON b.ename = e.ename
JOIN dept d ON d.deptno = e.deptno
WHERE b.ename = 'Scott'
FOR UPDATE OF b.ename;
END;
/
While in 10g (10.2) this code ends successfully (well NO_DATA_FOUND exception is raised but that is expected), in 11g (11.2) it raises exception "column ambiguously defined". And that is definitely not expected. It seems like it does not take into account table alias because I found out that when I change the column in FOR UPDATE OF e.empno (also does not work) to e.mgr (which is unique) it starts working. So is this some error in 11g? Any thoughts?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是 Oracle 11G 中的一个错误。在 11.2.0.2 版本中已修复。在此线程中对此进行了讨论: https://forums.oracle.com/forums /thread.jspa?threadID=2314477
It's a bug in Oracle 11G. It was fixed in 11.2.0.2 version. It has been discussed in this thread: https://forums.oracle.com/forums/thread.jspa?threadID=2314477
Oracle 10g 中有一个错误< /a> 已在 11g 中修复,其中 ORA-00918 列定义不明确 在应有的情况下没有被引发。我不确定这是否适用于您,因为您已经指定了所有别名。
Bonus.ename 上是否强制执行外键关系 -> emp.ename?
您是否尝试过使用非 ANSI 连接语法,例如:
There was a bug in Oracle 10g which was fixed in 11g where ORA-00918 column ambiguously defined was not being raised when it should have. I'm not sure if this applies to yours though because you have specified all aliases.
Is there a foreign-key relationship enforced on bonus.ename -> emp.ename?
Have you tried using the non-ANSI join syntax, e.g.: