Je sais que ce n'est pas une question très utile, mais je ne peux m'empêcher d'être dérangé par cela.Pourquoi le "Non" dans "ExecuteNonQuery"?
Ainsi,
Pourquoi ledit procédé (en cours *Command) est appelée
ExecuteNonQuery au lieu de ExecuteQuery?
Les instructions SQL que nous envoyons dans les bases de données ne sont-elles pas des requêtes?
sémantiquement, une requête est quelque chose que vous exécutez pour renvoyer des données. Vous 'interrogez' la base de données pour trouver tous les X dans le Y.
Si vous n'attendez pas de résultats en retour, ce n'est pas tant une requête que c'est une instruction ou une commande.
pas si elles sont, effacements INSERTS CREER TABLEs, etc.
Mais une méthode qui ** peut ** exécuter une requête (c'est-à-dire SELECT) ne doit pas être appelée ExecuteNonQuery. C'est ce qui me dérange. –
Il peut * exécuter * un SELECT, mais il est inutile d'utiliser 'ExecuteNonQuery' avec un' SELECT', car il ne renvoie pas de résultat. –
@Camilo Les classes DB ne savent pas si vous avez besoin d'une réponse expliquant explicitement à l'objet DB que vous ne vous attendez pas à ce que quoi que ce soit fasse de la place pour des optimisations. En tant que dev, vous ne voulez rien récupérer par une instruction select (sélectionnez * dans ... pour un) –
J'y penserais car une requête demande à la base de données de récupérer des enregistrements. Les actions qui altèrent les données/la base de données ne seraient pas une requête.
Mais cela peut être un SELECT. Alors pourquoi ne pas simplement "myCommand.Execute()"? –
@Camilo: Parce qu'il y a ExecuteReader() qui retournera les résultats de votre requête, ou même ExecuteScalar(), pour les résultats à valeur unique. –
Merci, je ne savais pas d'ExecuteScalar :) –