SqlDataReader ist Tropfen Spalten nach dem Zufallsprinzip!

Question

Ich habe ein sehr seltsames Problem, ich verwende System.Data.SqlClient. , um Daten von einem SQL Server über eine gespeicherte Prozedur zu erhalten. Wenn ich die Anwendung bei der Entwicklung und Stagging Maschinen testen es funktioniert gut, aber wenn ich implementieren die Anwendung auf dem Production Server I zufällig ein SqlDataReaderIndexOutOfRangeException mit unterschiedlichen Spaltennamen bekommen !.

Der Fehler erscheint in 2 Anfragen pro 1000 Anfrage (approximativ).

Das SQL Server Clustered

Source Code:

public static List<CountryInfo> GetAllCountries(){ 
      List<CountryInfo> Items = new List<CountryInfo>(); 
      try{ 
       using (rdr = SqlHelper.ExecuteReader(Globals.ConnectionString, "unv_spGetAllCountries")) 
       { 
        while (rdr.Read()) 
        { 
         CountryInfo item = new CountryInfo(); 
         item.CountryId = Convert.ToInt32(rdr["CountryId"]); 
         item.CountryName = rdr["CountryName"].ToString(); 
         item.FirstLevel = rdr["FirstLevel"].ToString(); 
         item.SecondLevel = rdr["SecondLevel"].ToString(); 

         Items.Add(item); 

        } 
       } 
      } 
      catch (Exception ex) 
      { 
       throw ex; 
      } 

      Items.TrimExcess(); 
      return Items; 
     } 

Stored Procedure:

select * from unv_tblCountries order by CountryName; 

Bereits Getestet

• Überprüfen Sie die Spaltennamen der Stored Procedure.
• Prüfen Sie die Spaltennamen der Reader.
• Überprüfen Sie die Verbindung String.

Wer konfrontiert dieses Problem und löst es?

Answer 1

Ich fand es die SqlDataReader Varibale rdr als static in den Controllern Basisklasse erklärt wurde, die es maked eine gemeinsame Varibale zwischen allen Controllern. Die Requests-Threads verwendeten dasselbe DataReader und änderten die darin enthaltenen Spalten.

Answer 2

Ich wette, das ist kein Problem mit dem Datenleser. Meine Vermutung wäre, dass ein oder mehrere Benutzerkonten eine spezifischere (und ältere) Kopie des Sprocs (etc) verwenden - zum Beispiel Fred.MyProc anstelle von dbo.MyProc, oder es gibt eine bedingte Verzweigungslogik im Sproc, die zurückkehrt in einigen Fällen unterschiedliche Spalten - vielleicht ein Codezweig, den Sie vergessen haben zu aktualisieren.

Ein anderes mögliches Problem ist möglicherweise andere Groß-/Kleinschreibung in der DB, die verschiedene zu verwendende Objekte verursacht; d. h. Myproc vs MyProc - was unterschiedlich sein kann, wenn die DB die Groß- und Kleinschreibung unterscheidet.

Um sicher herauszufinden, fügen Sie eine SQL-Ablaufverfolgung an Protokoll genau was (und von wem) für die fehlgeschlagenen Fälle gesendet wird; dann repro, dass in etwas wie SSMS, vergleichen Sie Dev zu prod.