Проблема DBNull с поставщиком Oracle 11g ODP.Net

Возникла проблема при проверке выходных параметров на «DBNull». Значение «DBNull», возвращаемое хранимой процедурой или функцией Oracle, обрабатывается клиентом oracle 11g / поставщиком ODP.Net как «пустая» строка. Это отлично работает с клиентом oracle 10g, поскольку он возвращает «DBNull». Из-за этого вся наша проверка «DBNull» не проходит.


oracle11g odp.net
person Hiscal    schedule 09.06.2010    source источник
comment
Итак ... в чем вопрос? Вы ожидаете, что кто-то скажет что-нибудь, кроме проверки значения по DBNull и null?   -  person Joel Mueller    schedule 09.06.2010

Ответы (3)


arrow_upward
5
arrow_downward

ODP.NET ВОЗВРАЩАЕТ СТРОКУ "NULL", ЕСЛИ ЗНАЧЕНИЕ НУЛЕВО [ID 968857.1]

    Modified 04-JAN-2010 Type PROBLEM Status PUBLISHED

В этом документе Признаки Изменения Причина Решение

Применимо к: Oracle Data Provider для .NET - версии: с 10.2.0.2.20 до 11.1.0.7.10 Microsoft Windows (32-разрядная версия) Microsoft Windows x64 (64-разрядная версия)

Симптомы После перехода с предыдущей версии Oracle Data Provider для .NET может произойти изменение поведения в отношении извлекаемых нулевых значений. В то время как приложение ранее возвращало пустую строку, теперь получается строка со значением «null». Изменяет миграцию с 1.x ODP.NET на 2.x ODP.NET

Причина. Такое поведение вызвано переходом с поставщика данных Oracle 1.x для .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 framework, а не изменение версии клиента Oracle, которое вызывает такое поведение.

Такое поведение также можно заметить при переносе приложения на 64-битную операционную систему, поскольку 64-битная структура 1.x отсутствует.

Решение Чтобы решить эту проблему, необходимо изменить код.

В качестве обходного пути использование ODP.NET для 1.x (например, 1.111.7.0 вместо 2.111.7.0) приведет к предыдущему поведению, но обратите внимание, что поставщик 1.x не тестируется и не поддерживается ни в одной из версий платформы, кроме чем 1.x, и что поддержка 1.x не планируется ни для одной из версий позже 11.1.0.7.0

Если операционная система 64-разрядная, приложение необходимо будет принудительно запустить в подсистеме SYSWOW64 (т. Е. Как 32-разрядную), чтобы использовать 1.x ODP.NET.

Чтобы исправить код:

Если значение - DbType, вы можете проверить param.Value == DbNull.Value

Если значение - OracleDbType, вы можете проверить ((INullable) param.Value) .IsNull, поскольку типы Oracle наследуют интерфейс INullable.

person Peter    schedule 25.06.2010
comment
Спасибо за это! Только что обновил старый сайт .NET до версии 4.7, и это вызывало у меня головные боли. Для склонных к VB: If Not CType(cmd.Parameters("paramName")?.Value, INullable).IsNull Then - person Andrew S; 06.04.2018

arrow_upward
2
arrow_downward

После критического изменения, выпущенного Oracle (см. Комментарий ниже). Вам нужно добавить дополнительный бит ниже:

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

INullable находится в пространстве имен Oracle.DataAccess.Types.

person Peter    schedule 25.06.2010

arrow_upward
1
arrow_downward

Или вы можете попробовать ...

(OracleString)result == OracleString.Null
person Ray Cheng    schedule 14.01.2015