使用记录作为参数调用 Oracle 存储过程
是否可以使用记录类型作为 IN 参数来调用 Oracle 存储过程?
在 Oracle 中,我有一个记录定义:
TYPE R_InData_tab IS RECORD ( ... );
TYPE InData_tab IS TABLE OF R_InData_tab INDEX BY BINARY_INTEGER;
现在我想将此记录类型设置为参数:
PROCEDURE myProcedure (inRecord IN myPackage.InData_tab);
并从我的 C# 代码中调用此过程。
有人有想法吗?
谢谢
Is it possible to call an Oracle stored procedure with a record type as IN parameter?
In Oracle I have a record definition:
TYPE R_InData_tab IS RECORD ( ... );
TYPE InData_tab IS TABLE OF R_InData_tab INDEX BY BINARY_INTEGER;
Now I want to set this record type as parameter:
PROCEDURE myProcedure (inRecord IN myPackage.InData_tab);
And call this procedure from my C# Code.
Does anyone have an idea?
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为您仅限于 Oracle 类型。如果是这样,您将必须编写一个存储过程,该过程采用常规参数、构造类型值并调用原始过程。
I think you are limited to the built-in Oracle types defined in OracleType. If so you would have to write a stored procedure that takes regular parameters, constructs the type value and calls the original procedure.
您可以通过发送代码块作为语句来完成此操作(自从我使用 Oracle 以来已经有一段时间了,因此语法可能略有偏差:
然后将 field1 和 field2 参数绑定到数组。
You can do this by sending a code block as the statement (it's been a while since I worked with Oracle so the syntax might be slightly off:
and then you bind the field1 and field2 parameters to arrays.
如果您使用 Oracle Data Provider for .NET(ODP.NET),那么绝对可以 直接调用该过程,而不使用 erikkallen 建议的按摩。
但是,我不确定这能解决您的问题。看起来您正在包含该过程的包中定义类型。为了使用上面链接的方法,您的类型需要在数据库中创建为单独的对象,使用 DDL 如下所示:
这可能需要对包进行一些细微的更改,因为 INDEX BY 类型不支持作为架构对象,因此嵌套需要使用表(或变量)。
If you're using Oracle Data Provider for .NET(ODP.NET), it's definitely possible to call the procedure directly without using the massaging suggested by erikkallen.
However, I'm not sure that will solve your problem. It looks like you're defining the types in the package that contains the procedure. In order to use the method linked above, your types need to be created as separate objects in the database, using DDL like so:
This may require some slight changes in the package, as INDEX BY types are not supported as schema objects, so nested tables (or varrays) will need to be used.