Warum ist OdbcCommand.ExecuteScalar () wirft einen Access?

Question

Ich habe einen Code-Block bestimmt Textbeschreibungen aus einer Datenbanktabelle zu ziehen und sie in eine Textdatei speichern. Es sieht aus wie dieser (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();

Dieser Code wird erfolgreich gespeichert einen Teil der Datendateien .txt, aber für viele Reihen wird ein Access in der folgenden Zeile geworfen:

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

Der Text der Ausnahme ist „Versucht zu geschützten Speicher zu lesen oder schreiben. Dies ist häufig ein Hinweis darauf, dass andere Speicher beschädigt ist“.

Das Programm wird in der Regel die Ausnahme auf den gleichen Zeilen der Tabelle werfen, aber es scheint nicht zu 100% konsistent zu sein. Manchmal Daten, die die Ausnahme in der Vergangenheit geworfen hatten plötzlich arbeiten.

Einige Leute fragen sich sicherlich, warum ich einfach nicht ID SELECT, ItemDescription aus Positionen des getItemsCommand und überspringen Sie die zweite Abfrage. Eigentlich hat sie es auf diese Weise zunächst, und ich war die Begegnung mit dem gleichen Fehler mit getItemsCommand.GetString (). Ich hatte Angst, dass vielleicht der Datensatz wurde zu viel Speicher Aufnahme und vielleicht war das den Fehler verursacht. Also habe ich beschlossen, diese Methode zu versuchen, um zu sehen, ob es helfen würde. Es kam nicht. Weiß jemand, warum dies geschieht könnte?

Durch die Art und Weise, ID ist ein INT und ItemDescription ist ein VARCHAR (32000) Spalte. Wenn es einen Unterschied macht, ist die Datenbank Borland Interbase 6.0 (Ick!)

EDIT: Ich habe die falsche Linie bei der Beschreibung, wo die Ausnahme ausgelöst wurde !! ARGH !! nun behoben. Außerdem habe ich versucht, die Dinge so Ahnung, aber sie hat nicht geholfen. Ich fand jedoch, dass nur sehr alte Datensätze in der Datenbank diesen Fehler verursacht wurden, die seltsam ist. Wenn ich die Abfrage nur Pull-Aufzeichnungen in den letzten 5 Jahren eingeführt zu ändern, gibt es keine Probleme. Jemand schlug vor, mir dies könnte eine Codierung Umwandlung Problem oder so etwas wie das sein?

Update: es wird gelöst. Das Problem stellte sich heraus, für unsere nicht sehr zuverlässige Datenbank-Software einen Fehler in dem ODBC-Treiber zu sein. Eine Abhilfe mit anderen Fahrern das Problem behoben.

Answer 1

Es könnte ein Fehler in dem ODBC-Treiber sein, die Sie verwenden. Welche Fahrer ist es? Was ist Ihre Verbindungszeichenfolge?

Answer 2

Ein Schuss im Dunkeln hier ...

Versuchen Sie, Ihre Leser Ausführen, Speichern Ihr Ergebnis (vielleicht in einem Array oder Liste), und sicherstellen, dass der Leser geschlossen wird, bevor die Ausführung oder den nächsten Befehl vorbereitet. Sie können sogar extreme gehen wollen und Ihre getItemsCommand Bau innerhalb eines using-Block zu setzen, so dass Sie wissen, dass es keine Ressourcen hat geöffnet, bevor Sie Ihren nächsten Befehl ausführen ...