Oracle 11g ODP.Net提供程序的DBNull问题

Question

我们在检查“DBNull”的输出参数时遇到了问题。由Oracle存储过程或函数返回的“DBNull”值被Oracle 11g客户端/ODP.Net提供程序视为“null”字符串处理。这在使用Oracle 10g客户端时可以正常工作，因为它返回“DBNull”。由于这个原因，我们所有的“DBNull”检查都失败了。

- Hiscal

---

所以...问题是什么？你期望有人说出除了“将值与DBNull和null都进行检查”之外的答案吗？ - Joel Mueller

Answer 1

ODP.NET在值为NULL时返回“NULL”字符串[ID 968857.1]

    Modified 04-JAN-2010 Type PROBLEM Status PUBLISHED               

在本文档中 症状 更改 原因 解决方案

适用于： Oracle Data Provider for .NET - 版本：10.2.0.2.20至11.1.0.7.10 Microsoft Windows（32位） Microsoft Windows x64（64位）

症状 从以前的Oracle Data Provider for .NET版本迁移后，可能会发生与检索空值有关的行为更改。应用程序以前返回一个空字符串，现在获取一个值为“null”的字符串。

更改 从1.x ODP.NET迁移到2.x ODP.NET

原因 该行为是由于从1.x Oracle Data Provider for .NET迁移到2.x提供程序引起的。2.x ADO.NET支持提供程序返回特定于提供程序的类型的能力，这是从.NET 1.x到2.x的潜在“破坏性变化”之一。

ODP.NET版本9.2.x、10.1.x、10.2.0.1.0都是1.x框架提供程序。通常，在从早期版本的ODP迁移到新版本的ODP时，会注意到此行为，但同时从1.x提供程序切换到2.x提供程序。导致此行为的是.NET框架支持的更改，而不是Oracle客户端版本的更改。

当将应用程序迁移到64位操作系统时，也可能会注意到此行为，因为没有1.x 64位框架。

解决方案 要解决此行为，需要修改代码。

作为解决方法，使用ODP.NET 1.x（例如1.111.7.0而不是2.111.7.0）将导致先前的行为，但请注意，1.x提供程序未在任何1.x以外的框架版本上进行测试或支持，并且不计划在11.1.0.7.0之后的任何版本中支持1.x。

如果操作系统是64位，则应用程序需要被强制运行在SYSWOW64子系统下（即32位），以便使用1.x ODP.NET。

更正代码：

如果值是DbType，则可以检查param.Value==DbNull.Value 如果值是OracleDbType，则可以检查((INullable)param.Value).IsNull，因为Oracle类型继承了INullable接口。

- Peter

---

谢谢！我刚把一个旧的.NET网站更新到4.7，这让我头疼不已。对于VB倾向的人来说：If Not CType(cmd.Parameters("paramName")?.Value, INullable).IsNull Then - Andrew S

Answer 2

在Oracle发布了重大变更之后（请参见下面的评论）。您需要添加以下附加位:

if (oraParam[7] == null || 
    oraParam[7].Value == DBNull.Value ||
    ((INullable)oraParam[7].Value).IsNull)

INullable位于Oracle.DataAccess.Types命名空间中。

- Peter

Answer 3

或者你可以尝试...

(OracleString)result == OracleString.Null

- Ray Cheng