Pourquoi OdbcCommand.ExecuteScalar () lève-t-il une exception AccessViolationException?

Question

J'ai un bloc de code destiné à extraire des descriptions de texte d'une table de base de données et à les enregistrer dans un fichier texte. Cela ressemble à ceci (C # .NET):

        OdbcCommand getItemsCommand = new OdbcCommand("SELECT ID FROM ITEMS", databaseConnection);
        OdbcDataReader getItemsReader = getItemsCommand.ExecuteReader();
        OdbcCommand getDescriptionCommand = new OdbcCommand("SELECT ITEMDESCRIPTION FROM ITEMS WHERE ID = ?", databaseConnection);
        getDescriptionCommand.Prepare();
        while (getItemsReader.Read())
        {
            long id = getItemsReader.GetInt64(0);
            String outputPath = "c:\\text\\" + id + ".txt";
            if (!File.Exists(outputPath))
            {
                getDescriptionCommand.Parameters.Clear();
                getDescriptionCommand.Parameters.AddWithValue("id", id);
                String description = (String)getDescriptionCommand.ExecuteScalar();
                StreamWriter outputWriter = new StreamWriter(outputPath);
                outputWriter.Write(description);
                outputWriter.Close();
            }
        }
        getItemsReader.Close();

Ce code a correctement enregistré une partie des données dans des fichiers .txt, mais pour de nombreuses lignes, une exception AccessViolationException est renvoyée sur la ligne suivante:

                String description = (String)getDescriptionCommand.ExecuteScalar();

Le texte de l'exception indique "Tentative de lecture ou d'écriture en mémoire protégée". Cela indique souvent qu'une autre mémoire est corrompue ".

Le programme lèvera généralement l'exception sur les mêmes lignes de la table, mais cela ne semble pas être cohérent à 100%. Parfois, les données qui ont généré une exception par le passé fonctionnent soudainement.

Certaines personnes se demandent sans doute pourquoi je n'ai pas simplement SELECT ID, ITEMDESCRIPTION FROM ITEMS dans la commande getItemsCommand et ignoré la seconde requête. En fait, je l’ai fait de cette façon au début et j’étais confronté à la même erreur avec getItemsCommand.GetString (). J'avais peur que l'ensemble de données prenne trop de mémoire et que cela cause peut-être l'erreur. J'ai donc décidé d'essayer cette méthode pour voir si cela aiderait. Ça n'a pas. Quelqu'un sait-il pourquoi cela pourrait se produire?

Au fait, ID est une INT et ITEMDESCRIPTION est une colonne VARCHAR (32000). Si cela fait une différence, la base de données est Borland Interbase 6.0 (Ick!)

EDIT: Je me suis trompé de ligne en décrivant où l'exception a été lancée !! ARGH !! Correction maintenant. En outre, j'ai essayé les choses suggérées jusqu'à présent, mais elles n'ont pas aidé. Cependant, j'ai constaté que seuls de très vieux enregistrements de la base de données étaient à l'origine de cette erreur, ce qui est étrange. Si je modifie la requête pour extraire uniquement les enregistrements insérés au cours des 5 dernières années, il n'y a pas de problèmes. Quelqu'un m'a suggéré que cela pourrait être un problème de conversion d'encodage ou quelque chose comme ça?

Mise à jour: résolu. Le problème s'est avéré être un bogue dans le pilote ODBC de notre logiciel de base de données peu fiable. Une solution de contournement avec d'autres pilotes a corrigé le problème.

Answer 1

Il pourrait s'agir d'un bogue dans le pilote ODBC que vous utilisez. De quel pilote s'agit-il? Quelle est votre chaîne de connexion?

Answer 2

Un tir dans le noir ici ...

Essayez d’exécuter votre lecteur, d’enregistrer votre résultat (éventuellement dans un tableau ou une liste) et de vous assurer que le lecteur est fermé avant d’exécuter ou de préparer la commande suivante. Vous pouvez même vouloir aller très loin et placer votre construction getItemsCommand dans un bloc using afin que vous sachiez qu'il n'a pas de ressources ouvertes avant d'exécuter votre prochaine commande ...