Xml Biztalk无法读取具有强类型ref游标的Oracle 18存储过程

我们必须通过调用存储过程从Oracle中的表中读取数据。该存储过程返回一个强类型游标，并且在Oracle 12上运行良好

更新到Oracle 18将返回一个响应，就像游标是弱类型的一样：

这个链接有我们正面临的问题，但是游标是强类型的

我尝试使用record和explicity返回ref游标，指定列名和类型。它不起作用。Biztalk版本为2013 R2

有人在Oracle 18中遇到过这个问题吗？与Oracle 12配合良好

强类型游标是

TYPE t_ReqCursor is REF CURSOR RETURN REQUEST%ROWTYPE

Biztalk正在阅读的内容是这样的

<GenRecordRow xmlns="http://Microsoft.LobServices.OracleDB/2007/03">
        <GenRecordColumn>
            <GenRecordColumn>
                <ColumnName>AGNCY_RQST_ID</ColumnName>
                <ColumnValue>545</ColumnValue>
                <ColumnType>System.Int64</ColumnType>
            </GenRecordColumn>
            <GenRecordColumn>
                <ColumnName>RQST_ID</ColumnName>
                <ColumnValue>4344</ColumnValue>
                <ColumnType>System.Int64</ColumnType>
            </GenRecordColumn>
</GenRecordRow>

AGNCY_RQST_ID
545
System.Int64
RQST_ID
4344
System.Int64

Oracle database 11.2是technet文章中指定的Biztalk 2013 R2支持的最新版本

---

我想你证明了BizTalk对于Oracle 18来说并不是完全崩溃的，只是部分崩溃。从长远来看，您可以使用BizTalk 2016进行一些测试，因为它支持Oracle数据库12.1。仍然不是您想要的版本，但值得一试（或者等待BizTalk 2020的预览版本，并希望获得Oracle 18的实际支持）

我在BizTalk 2016连接Oracle19c时遇到了同样的问题，当前的设置是BizTalk2016和Oracle12c。Oracle计划更新到最新的Oracle19c版本

因此，基于此设置，我们知道BizTalk2016将不支持Oracle19c DB。我们使用紧密耦合的WCF OracleDB适配器。我们尝试了所有常见的怀疑，例如升级Oracle客户端、BizTalk Server中的ODAC组件。 以下格式未更改为原始格式

因此，我们尝试在Oracle方面进行分析，以比较Oracle12c和Oracle19/18c之间的变化。基本上，我们查看了DB文档中所有被贬低的功能。我们在下面找到了

参考：

摘自Oracle文档“如果您希望继续收集ARGUMENTS视图中的所有_类型和关联的用户视图、所有_类型属性和所有_COLL_类型，则可以将事件设置为events='10946，level 65536'。设置此事件会将ARGUMENTS视图还原为早于12.1的Oracle数据库版本中的行为，在该版本中，数据_级别可以大于。”0，并且该类型和任何嵌套类型的描述性元数据包含在视图中。如果进行此更改，则必须在设置事件后重新编译受影响的包。重新编译受影响的包时，编译器将重新收集其他元数据。此事件还将还原为OCISCRIBEANY（）在12.1之前的Oracle数据库版本中的行为”

根据最新版本DB中的上述文档，他们将参数列表移动到三个不同的表中

• **所有PLSQL类型
• 所有类型属性
• 所有类型**

这对于BizTalk很重要，因为BizTalk正在查找此表中的架构信息

all_arguments

既然Oracle已将架构/元数据信息移动到新表中，BizTalk的架构呈现与Oracle12与Oracle19/18c不同

因此，我们在会话中设置/复制上述事件，并尝试重新编译BizTalk包，BizTalk2016开始正常工作

1. alter session set events '10946 trace name context forever, level 65536';
2. alter package <package_name> compile;

1.alter session set events'10946 trace name context forever，level 65536'；
2.修改包编译；

这只是一个解决方案，并不是一个实际的解决方案。但在我们重新编写代码之前的短期内，这将起作用

注意：我们仍在测试解决方案的所有方面，如解决方案中的性能/负载测试。我们还没有弄清楚此解决方案的副作用。如果我们发现任何问题，我将随时发布