ORACLE:WHERE 中的参数引用不起作用
我在oracle 10g中创建了一个简单的静态函数来根据对象的pk获取对象的引用。
STATIC FUNCTION getRef(nome IN VARCHAR2)
RETURN REF folder_typ IS
fl_r REF folder_typ := null;
BEGIN
SELECT REF(fl)
INTO fl_r
FROM folder_tab fl
WHERE fl.nome = nome;
RETURN fl_r;
END getRef;
这给了我一个错误,因为它无法获取行。 如果安装了 WHERE fl.nome = nome;
我写 WHERE fl.nome = 'folder1';
——它可以工作。
我认为我没有以正确的方式使用该参数。 我该如何使用它?
I have created a simple static function in oracle 10g to get the reference of an object based on his pk.
STATIC FUNCTION getRef(nome IN VARCHAR2)
RETURN REF folder_typ IS
fl_r REF folder_typ := null;
BEGIN
SELECT REF(fl)
INTO fl_r
FROM folder_tab fl
WHERE fl.nome = nome;
RETURN fl_r;
END getRef;
This gives me an error because it could't fetch a row.
If insted of WHERE fl.nome = nome;
I write WHERE fl.nome = 'folder1';
-- it works.
I think im not using the parameter in the right way.
How can I use it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是一个范围界定问题。
这是我对您的设置的版本,是根据您发布的内容推断出来的。请注意,参数名称与属性名称不同。
正如你所看到的,给定这个测试数据……
我可以查询两个 REF:
但是,如果我更改函数声明,使参数名称与属性名称相同,则会发生这种情况:
SQL 引擎应用作用域从桌子向外。因为不合格的
NAME
与表中的列匹配,所以它不会检查是否也存在该名称的参数。这就是为什么给参数起一个独特的名称是个好主意。就我个人而言,我更喜欢在参数前加上P_
前缀的做法,这样参数就不会与局部变量或对象名称发生冲突。This is a scoping problem.
Here is my version of your set-up, extrapolated from what you posted. Note that the parameter name is different from the attribute name.
As you can see, given this test data ...
... I can query the two REFs:
But, if I change the function declaration so the parameter name is the same as the attribute name, this happens:
The SQL engine applies scope from the table outwards. Because the unqualified
NAME
matches a column on the table it doesn't check to see that whether there is a parameter of that name too. This is why it is a good idea to give the parameters a distinct name. Persoanlly I favour the practice of prefixing parameters with aP_
, so there's no chance of the paremeter clashing with local variables or object names.最佳实践是始终提供所有变量的范围,而不仅仅是表别名中的变量:
Best practice is to always provide the scope for all variables, not just for those from table aliases: