IDataRecord.IsDBNull causes an System.OverflowException (Arithmetic Overflow)

I have a OdbcDataReader that gets data from a database and returns a set of records.

The code that executes the query looks as follows:

OdbcDataReader reader = command.ExecuteReader();

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

The method returns an IEnumerable of a custom type (MovexProduct). The convertion from an IDataRecord to my custom type MovexProduct happens in an extension-method that looks like this (abbrev.):

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;
}

As soon as I hit the if (!record.IsDBNull(4)) I get an OverflowException with the exception message "Arithmetic operation resulted in an overflow."

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) [...]

I've never encountered this problem before and I cannot figure out why I get it. I have verified that the record exists and that it contains data and that the indexes I provide are correct. I should also mention that I get the same exception if I change the if-statemnt to this: if (record.GetString(4) != null). What does work is encapsulating the property-assignment in a try {} catch (NullReferenceException) {} block - but that can lead to performance-loss (can it not?).

I am running the x64 version of Visual Studio and I'm using a 64-bit odbc driver.

Has anyone else come across this? Any suggestions as to how I could solve / get around this issue?

Many thanks!

For any one experiencing the same issue, the way I solved this was to switch from the Odbc* classes to their OleDb* counterparts. This of course demands that your data driver has support for OleDb connections.

Which DB are you trying to talk to? If it uses some "private" column types that can cause problems. That doesn't apply to SQL Server of course :-)

Also check that you are compiling and running as x64 (Process Explorer will show you thsi and even plain tack manager shows it). devenv.exe will still be x86 but your actual binary should run as x64. The reason I mention is that crossing 32/64 bit boundary is notorious for breaking 3rd party ODBC drivers.