IDataRecord.IsDBNull вызывает исключение System.OverflowException (арифметическое переполнение) - PullRequest
1 голос
/ 30 марта 2010

У меня есть OdbcDataReader, который получает данные из базы данных и возвращает набор записей.

Код, который выполняет запрос, выглядит следующим образом:

OdbcDataReader reader = command.ExecuteReader();

while (reader.Read())
{
    yield return reader.AsMovexProduct();
}

Метод возвращает IEnumerable пользовательского типа (MovexProduct). Преобразование из IDataRecord в мой пользовательский тип MovexProduct происходит в методе расширения, который выглядит следующим образом (сокращенно):

public static MovexProduct AsMovexProduct(this IDataRecord record)
{
    var movexProduct = new MovexProduct
    {
            ItemNumber = record.GetString(0).Trim(),
            Name = record.GetString(1).Trim(),
            Category = record.GetString(2).Trim(),
            ItemType = record.GetString(3).Trim()
    };

    if (!record.IsDBNull(4)) 
        movexProduct.Status1 = int.Parse(record.GetString(4).Trim());

    // Additional properties with IsDBNull checks follow here.

    return movexProduct;
}

Как только я нажимаю if (!record.IsDBNull(4)), я получаю исключение OverflowException с сообщением об исключении "Арифметическая операция привела к переполнению."

StackTrace: System.OverflowException was unhandled by user code Message=Arithmetic operation resulted in an overflow. Source=System.Data StackTrace: at System.Data.Odbc.OdbcDataReader.GetSqlType(Int32 i) at System.Data.Odbc.OdbcDataReader.GetValue(Int32 i) at System.Data.Odbc.OdbcDataReader.IsDBNull(Int32 i) at JulaAil.DataService.Movex.Data.ExtensionMethods.AsMovexProduct(IDataRecord record) [...]

Я никогда не сталкивался с этой проблемой раньше, и я не могу понять, почему я ее получаю. Я проверил, что запись существует и что она содержит данные и что индексы, которые я предоставляю, верны. Я должен также упомянуть, что я получаю то же исключение, если я изменяю if-statemnt на это: if (record.GetString(4) != null). Что работает, так это инкапсуляция присваивания свойства в блоке try {} catch (NullReferenceException) {}, но это может привести к снижению производительности (не так ли?).

Я использую 64-разрядную версию Visual Studio и использую 64-разрядный драйвер odbc.

Кто-нибудь еще сталкивался с этим? Какие-нибудь предложения относительно того, как я мог решить / обойти эту проблему?

Большое спасибо!

Ответы [ 2 ]

0 голосов
/ 22 июля 2010

С какой БД вы пытаетесь общаться? Если он использует некоторые «частные» типы столбцов, которые могут вызвать проблемы. Это не относится к SQL Server, конечно: -)

Также проверьте, что вы компилируете и работаете как x64 (Process Explorer покажет вам это, и даже простой менеджер галстука это покажет). devenv.exe по-прежнему будет x86, но ваш двоичный файл должен работать как x64. Причина, о которой я упоминаю, заключается в том, что пересечение 32/64 битной границы печально известно нарушением сторонних драйверов ODBC.

0 голосов
/ 20 апреля 2010

Для любого, кто сталкивался с той же проблемой, я решил эту проблему, переключившись с классов Odbc * на их аналоги OleDb *. Это, конечно, требует, чтобы ваш драйвер данных поддерживал соединения OleDb.

...