2010-03-30 6 views
1

J'ai un OdbcDataReader qui obtient des données d'une base de données et retourne un ensemble d'enregistrements.IDataRecord.IsDBNull provoque une exception System.OverflowException (dépassement arithmétique)

Le code qui exécute la requête se présente comme suit:

OdbcDataReader reader = command.ExecuteReader(); 

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

La méthode retourne un IEnumerable d'un type personnalisé (MovexProduct). La convertion d'un IDataRecord à mon type personnalisé MovexProduct se produit dans une extension méthode qui ressemble à ceci (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; 
} 

Dès que je frappe le if (!record.IsDBNull(4)) je reçois un OverflowException avec le message d'exception « opération arithmétique entraîné un débordement. "

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

Je ne l'ai jamais rencontré ce problème avant et je ne peux pas comprendre pourquoi je l'obtiens. J'ai vérifié que l'enregistrement existe et qu'il contient des données et que les index que je fournis sont corrects. Je devrais également mentionner que j'obtiens la même exception si je change l'if-statemnt à ceci: if (record.GetString(4) != null). Qu'est-ce que le travail encapsule l'affectation de propriété dans un bloc try {} catch (NullReferenceException) {} - mais cela peut entraîner une perte de performance (n'est-ce pas?). Je lance la version x64 de Visual Studio et j'utilise un pilote odbc 64 bits.

Est-ce que quelqu'un d'autre est tombé dessus? Des suggestions sur la façon dont je pourrais résoudre/contourner ce problème?

Merci beaucoup!

+0

Quel est le type de données en sql de la colonne qui est récupérée au 4ème index? – HotTester

+0

C'est un GRAPHIC() CCSID 13488 (2), quel que soit (?). – Ciddan

Répondre

0

Pour tous ceux qui ont connu le même problème, la façon dont j'ai résolu cela était de passer des classes Odbc * à leurs homologues OleDb *. Cela exige bien sûr que votre pilote de données supporte les connexions OleDb.

0

Avec quel DB voulez-vous parler? S'il utilise des types de colonnes "privés" qui peuvent causer des problèmes. Cela ne s'applique pas à SQL Server bien sûr :-)

Vérifiez également que vous compilez et exécutez en tant que x64 (Process Explorer vous montrera thsi et même le gestionnaire de harcèlement simple le montre). devenv.exe sera toujours x86 mais votre binaire actuel devrait fonctionner sous x64. La raison que je mentionne est que la frontière de passage de 32/64 bits est notoire pour casser des conducteurs d'ODBC tiers.

Questions connexes