Différents moyens de passer des paramètres sqlCommand

Question

Il y a une question liée à ceci:

Quelle est la meilleure méthode pour passer des paramètres à SQLCommand?

Mais je suis désireux de savoir quelles sont les différences et, si il y a des problèmes avec les diverses manières.

J'ai l'habitude d'utiliser une structure à quelque chose comme ceci:

using (SqlConnection conn = new SqlConnection(connectionString))
using (SqlCommand cmd = new SqlCommand(SQL, conn))
{
     cmd.CommandType = CommandType.Text;
     cmd.CommandTimeout = Settings.Default.reportTimeout;
     cmd.Parameters.Add("type", SqlDbType.VarChar, 4).Value = type;

     cmd.Connection.Open();

     using (SqlDataAdapter adapter = new SqlDataAdapter(cmd))
     {
         adapter.Fill(ds);
     }
      //use data                    
}

Maintenant, il y a plusieurs façons d'ajouter de la cmd paramètres et je me demande qui est le mieux:

cmd.Parameters.Add("@Name", SqlDbType.VarChar, 20).Value = "Bob";
cmd.Parameters.Add("@Name", SqlDbType.VarChar).Value = "Bob";
cmd.Parameters.Add("@Name").Value = "Bob";
cmd.Parameters.AddWithValue("@Name", "Bob");

Ayant la longueur du champ dans le passage de la varchars je suppose n'est pas préférable, car c'est une valeur magique qui peut être changé plus tard à la base de données. Est-ce correct? Ne provoque aucun problème en passant un varchar de cette façon (performance ou d'autres), je suppose que c'est par défaut de type varchar(max) ou la base de données équivalent. Je suis raisonnablement satisfait de cette volonté de travail.

La partie qui m'inquiète plus, c'est la perte de la SqlDbType enum si je suis à l'aide de la troisième ou de la quatrième options que j'ai énumérés ci-dessus, je ne suis pas la fourniture d'un type à tous. Existe-il des cas où cela ne fonctionne pas, je peux imaginer des problèmes avec varchar mal exprimés char ou vice versa, ou peut-être des problèmes avec virgule pour de l'argent....

En termes de base de données le type de champ que je voudrais dire, c'est beaucoup moins susceptible de changer que la longueur est-il donc la peine de le garder?

Answer 1

Dans mon expérience, je voudrais m'assurer que je fais ces choses:

• assurez-vous que c'est vous qui définit le type de données du paramètre. ADO.NET un emploi décent à deviner, mais, dans certains cas, il peut être terriblement hors donc, je voudrais éviter cette méthode:

  cmd.Parameters.Add("@Name").Value = "Bob";
  cmd.Parameters.AddWithValue("@Name", "Bob");
  

  Laisser ADO.NET deviner le type du paramètre par la valeur transmise est délicat, et si c'est pour une raison quelconque, ceux qui sont vraiment difficile de bugs de suivre et de trouver! Imaginez ce qui se passe quand vous passez par un DBNull.Value - ce type de données doit ADO.NET choisir pour qui?

  Juste être explicite - à-dire quel type que vous voulez!

• si vous utilisez des paramètres de chaîne, assurez-vous de définir explicitement la longueur - donc, je voudrais éviter cette méthode, trop:

  cmd.Parameters.Add("@Name", SqlDbType.VarChar).Value = "Bob";
  

  Si vous ne fournissez pas une longueur, ADO.NET pourrait par défaut à l'arbitraire de la valeur, ou la longueur de la chaîne passée en tant que valeur, ou quelque chose d'autre, vous n'êtes jamais tout à fait sûr. Et si votre longueur ne correspond pas à ce que la procédure stockée vraiment attend, vous pourriez voir de conversion et autres mauvaises surprises. Donc, si vous définissez une chaîne de caractères, de définir sa longueur, trop!

Donc dans votre cas, la seule méthode qui fonctionne vraiment pour moi est celle-ci:

cmd.Parameters.Add("@Name", SqlDbType.VarChar, 20).Value = "Bob";

parce qu'il a définit le type de données à utiliser explicitement, et b) définit la longueur de la chaîne explicitement.

Answer 2

En ajoutant le type, vos demandes sont plus susceptibles d’améliorer les performances en utilisant un plan de requête en cache.

Devis MSDN

Les commandes paramétrées peuvent également améliorer les performances d'exécution des requêtes, car elles aident le serveur de base de données à faire correspondre avec précision la commande entrante avec un plan de requête mis en cache approprié.

Plus à lire dans la mise en cache et la réutilisation du plan d'exécution