Question

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!

Answer 1

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.