2010-10-29 7 views
6

Nach mehreren Stunden (~ 6 Stunden Win7 64bit, ~ 24hours WinXP) der Ausführung von Multi-Thread (.NET Framework 3.5 SP1 WinForms) Desktop-Anwendung mit .mdb-Dateien als Backend Ich bekomme den folgenden Laufzeitfehler:System.Data.OleDb.OleDbConnectionIntern..ctor: Unbekannter Fehler

Es sieht aus wie dies ist ein OleDbProvider Bug.

Haben Sie so etwas gesehen/erlebt?

Kontext:

(1) Ich verwende ausschließlich

using (OleDbConnection cnn = new OleDbConnection("{{mymdbConnectionStringHere}}")) {

cnn.Open();

...

}

(2) I-Klausel in einigen ausgewählten SQL-Ausdrücke verwenden IN auf externe MDB-Tabellen zu verweisen.

Ich denke, das Problem wird von Fall (2) verursacht. Obwohl dies immer noch eine Hypothese ist, die hier überprüft werden soll (einige Code-Fixes sind im Kerncode meiner Anwendung erforderlich, und ich denke, dass es sich lohnt, das Problem zu beheben, oder ich sollte besser zum MS SQL-Backend wechseln.)

Vielen Dank Sie.

+0

Am wahrscheinlichsten ist die Ausnahme bei der Open() -Aufruf, also überprüfen Sie Ihre Verbindungszeichenfolge, Datenbank-Anmeldeinformationen usw. –

+0

Nicht spezifizierter Fehler .. Muss die nützlichste Fehlermeldung in Existenz sein. –

+0

@Mamta Dalal: Wenn das Problem nach mehreren Stunden auftritt, ist es sicher nicht die Verbindungszeichenfolge und Datenbank-Anmeldeinformationen ..Ich habe das gleiche Problem, und ich bin auch bestrebt, eine Lösung zu finden. – Allie

Antwort

1

Ich habe Beispielanwendung Test geschrieben - das Problem wird durch einen Fehler irgendwo in den Interna von .NET System.Data.OleDb verursacht.

-Test VS2008 SP1 Lösung wird hier veröffentlicht: System.Data.OleDb bug demonstration sample.

+0

Auch wenn keine IN-Klausel verwendet wird (oder verknüpfte Tabellen), schlägt OleDb Beispielanwendung, die ich hier geschrieben habe, fehl, nach etwa 70.000 Verbindungen Kreationen/Zerstörungen - TestConnection.ERROR: Unbekannter Fehler - 29.10.2010 22:42:25: 7737. StartTime = 29.10.2010 21:59:33, EndTime = 29.10.2010 22:42:25, TotalCount = 69633, ElapsedTime = 0.7142 Stunden ... – ShamilS

3

Gab es Fortschritte bei der Suche nach der Lösung für dieses Problem oder mehr stabe Abhilfe aus?

Ich habe ähnliches Problem in ASP.NET-Anwendung mit Excel-Datei lesen. Es ist nur in Produktionsumgebungen sichtbar, in denen viele Benutzer versuchen, unterschiedliche XLS-Dateien auf der Serverseite zu verarbeiten. Nach dem Recyceln des IIS-Dienstes in der Nacht gibt es ungefähr ~ 200 Anfragen (um Excel zu öffnen), die JET-Engine hängen. Das Problem ist, dass alle nachfolgenden Versuche fehlschlagen, so dass Wiederholungslogik nicht viel helfen würde. Nur IIS-Reset heilt das Problem.

Aus der Untersuchung die ich gemacht habe gibt es mehrere Möglichkeiten zu nehmen:

  1. Umschalten auf andere Bibliothek zu XLS-Dateien zu lesen: Excel OLE Automation - erfordert Excel auf dem Server installiert werden und viele Anfragen haben würde Erstellen Sie viele Instanzen von Excel-Prozessen, die nicht akzeptabel sind. 3rd Party Bibliothek - sind diese kostenlos?
  2. Verschieben Sie die Excel-Verarbeitung, um den Prozess zu trennen. Tauschen Sie Daten mit einem anderen Format als XML aus.
  3. Verwenden Sie eine Art von Smart-Handling, um die Anzahl der offenen und geschlossenen OLEDB im Prozess zu steuern.

Irgendwelche Gedanken?

+0

Testen Sie OpenXML SDK, um XLSX-Dateien zu lesen. – ShamilS

2

Ich hatte das gleiche Problem. Recyling nur der Anwendungspool in IIS funktionierte für mich.

+0

Haben Sie in irgendeiner Weise gelöst? –

+0

Auch für mich gearbeitet! Vielen Dank! –