suppose
que la requête SQL contient une instruction
SELECT. Comme ADO.NET
n’accepte que la première colonne de la première ligne, il convient de limiter
l’ensemble de lignes à  une valeur,
comme vous le faites quand vous utilisez
SELECT pour renvoyer une variable
de serveur. Mais, comme vous utilisez
encore une instruction SELECT dans
ce cas, renvoyer un objet scalaire n’est
pas aussi efficace que renvoyer le paramètre
OUTPUT ou ReturnValue.

Examinons du code qui démontre
ces deux méthodes. Le code du listing
1 utilise la méthode ExecuteScalar
pour exécuter une procédure stockée
(qu’illustre le listing 2) qui ajoute une
nouvelle ligne à  la table Northwind
Orders et renvoie un objet scalaire (un
entier) contenant le nouveau OrderID
que SQL Server génère.

Le code du listing 3 utilise la méthode
ExecuteNonQuery de l’objet
SqlCommand pour renvoyer la valeur
RowsAffected provenant de la procédure
stockée du listing 4 et les paramètres
renvoyés restants. Notez que le listing 3 montre deux manières de renvoyer
des valeurs à  partir de la procédure
stockée : avec un paramètre OUTPUT
et avec un paramètre ReturnValue.
Vous pouvez utiliser les deux pour renvoyer
de nouvelles valeurs d’identité
de ligne, des objets scalaires (nombres
ou chaînes) ou toute information qui
vous intéresse. N’oubliez pas qu’il est
bien plus rapide de gérer des paramètres
OUTPUT que de renvoyer un
ensemble de lignes.

Si vous évitez d’exécuter des requêtes
qui contiennent des instructions
SELECT quand votre question a
une réponse oui ou non numérique,
votre application s’exécutera plus rapidement
et sera plus extensible.

Inutile d’utiliser une instruction
SELECT pour savoir s’il reste des places
sur ce vol pour Cleveland – sauf si vous
voulez avoir la liste des voyageurs occupant
les places voisines. Et s’il y avait
une célébrité ?