La saisie semi-automatique provoque une panne

Question

J'ai une application Windows Form avec une poignée de champs, y compris un champ 'Société' et un champ 'Contact'. Lorsque vous tapez un élément dans le champ société et cliquez sur un bouton, il lance une requête dans une base de données SQL pour renseigner les informations de contact de cette société dans le champ "Contact". J'ai inclus une saisie semi-automatique vraiment basique dans le champ 'Société', principalement pour plus de commodité.

Le problème est que lorsque je charge le formulaire, dès que je tape quelque chose dans le champ 'Société', le programme se bloque. Il n'y a pas d'autres appels effectués sur une frappe et je l'ai réduit à l'autocomplétion causant les problèmes.

Le code qui gère tout est comme suit:

public void GetRowCount() 
    { 
     try 
     { 
      _DbRows = db.CountRows(); 
      tContact.Text = _DbRows.ToString(); 
     } 
     catch (Exception tEx) 
     { 
      MessageBox.Show("Exception in GetRowCount. Exception: " + tEx.Message); 
     } 
    } 
    private void GetCustomerList() 
    { 
     String customerQuery = "SELECT DISTINCT Name FROM Customers"; 

     try 
     { 
      _CustomerList = db.ReturnCustomers(customerQuery, _DbRows); 
     } 
     catch (Exception ex) 
     { 
      MessageBox.Show(ex.Message); 
     } 
    } 
    public void PopulateAutofillList() 
    { 
     try 
     { 
      tCompany.AutoCompleteSource = AutoCompleteSource.CustomSource; 
      tCompany.AutoCompleteCustomSource.AddRange(_CustomerList); 
      MessageBox.Show(_CustomerList.Length.ToString()); 
      tCompany.AutoCompleteMode = AutoCompleteMode.Append; 
     } 
     catch (Exception tEx) 
     { 
      MessageBox.Show("Exception On Autocomplete. Exception: " + tEx.Message); 
     } 
    } 

Ceux-ci sont tous appelés séparément dans une méthode OnLoad, comme ceci:

private void Form1_Load(object sender, EventArgs e) 
    { 
     try 
     { 
      GetRowCount(); 
      GetCustomerList(); 
      PopulateAutofillList(); 
     } 
     catch (Exception ex) 
     { 
      MessageBox.Show("Initial Connection to the Database Failed."); 
     } 
    } 

Et la DB requêtes:

public String[] ReturnCustomers(string sqlQuery, int size) 
    { 
     createConnectionString(); 
     StreamWriter file = new StreamWriter("dbCustomerList"); 
     int i = 0; 
     String[] results = new String[size]; 

     SqlConnection myConnection = new SqlConnection(_ConnectionString); 
     { 

      myConnection.Open(); 

      SqlCommand cmd = new SqlCommand(sqlQuery, myConnection); 
      { 
       SqlDataReader reader; 
       reader = cmd.ExecuteReader(); 

       while (reader.Read()) 
       { 
        Console.WriteLine(reader.GetString(0)); 
        results[i] = reader.GetString(0); 
        //file.WriteLine(i ": " + results[i]); 
        i++; 
       }  
       return results; 
      } 
     } 
    } 
    public int CountRows() 
    { 
     createConnectionString(); 
     int rows; 

     SqlConnection myConnection = new SqlConnection(_ConnectionString); 
     { 

      myConnection.Open(); 

      SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM Customers;", myConnection); 

      rows = Convert.ToInt32(cmd.ExecuteScalar()); 

      Console.Write("Row Count: " + rows); 
     } 

     return rows; 
    } 

Je ne suis pas totalement sûr de ce qui est cassé. Tous mes petits chèques qui apparaissent le long du chemin indiquent que les choses sont bien. Pour tester, j'ai tout cela fonctionnait sur SQLite et ça allait. Il a cassé quand je l'ai déplacé vers SQL.

-

Edit:

L'exception complète que Windows Small Business Server 2011 donne:

signature du problème: Nom de l'événement Problème: APPCRASH

Nom de l'application: SSLP.exe

Application Version: 1.0.0.0

application Timestamp: 5213d1b8

Module Défaut Nom: shell32.dll

Module de défaut Version: 6.1.7600.17038

Module de défaut Horodatage: 4fd2d370

Code d'exception: c0000005

Décalage d'exception: 000ac2c5

Version OS: 6.1.76 00.2.0.0.305.9

Locale ID: 1033

Informations supplémentaires 1: a7aa

Informations supplémentaires 2: a7aa91f17ea749d42a4de3b390fa5b3d

Informations complémentaires 3: a7aa

Informations complémentaires 4: a7aa91f17ea749d42a4de3b390fa5b3d

Answer 1

Ce code est plus qu'un peu funky. Le plus gros problème est de ne pas utiliser une liste dynamique. Ensuite, vous n'aurez pas besoin de deux appels DB. Vous n'aurez pas besoin du nombre, etc. Vous devez également utiliser using pour ces objets. Comme ceci:

public String[] ReturnCustomers(string sqlQuery, int size) 
{ 
    createConnectionString(); 
    StreamWriter file = new StreamWriter("dbCustomerList"); 
    List<string> results = new List<string>(); 

    using (SqlConnection myConnection = new SqlConnection(_ConnectionString)) 
    { 
     myConnection.Open(); 

     using(SqlCommand cmd = new SqlCommand(sqlQuery, myConnection)) 
     { 
      using(SqlDataReader reader = cmd.ExecuteReader()) 
      { 
       while (reader.Read()) 
       { 
       Console.WriteLine(reader.GetString(0)); 
       results.Add(reader.GetString(0)); 
       }  
      } 
     } 
     myConnection.Close(); 
    } 
    return results.ToArray(); 
} 

Answer 2

Bien , donc c'est le plus stupide des choses:

En désespoir de cause, j'ai parcouru toute la base de données à la recherche de quelque chose qui la rejetterait. Il y avait une entrée en double dans la base de données et je suppose qu'elle s'est cassée lorsque Total Rows (tel que retourné par CountRows) ne correspondait pas au nombre distinct de lignes.

Vraiment bête, mais après avoir supprimé les entrées en double, cela fonctionne.

Answer 3

Je suis tombé sur un problème similaire à ce sujet - saisir une liste de numéros à partir d'une base de données à utiliser comme source de saisie semi-automatique. En particulier, j'utilisais Linq en SQL et renvoyais une liste distincte. L'une des valeurs de cette liste distincte était null, ce qui provoquait le blocage de mon programme lorsque j'entrais une valeur dans la zone de texte avec la source de saisie semi-automatique. Impossible cependant de trouver une façon d'intercepter une exception, donc le débogage était un peu compliqué.

L'ajout d'un "where number! = Null" à ma requête Linq to SQL a résolu le problème pour moi.