Inspiré par cette question où les avis divergent sur SET NOCOUNT ...
Devrions-nous utiliser SET NOCOUNT ON pour SQL Server? Sinon, pourquoi pas?
What it does Edit 6, le 22 juillet 2011
Il supprime le message "xx lignes affectées" après tout DML. Il s'agit d'un jeu de résultats et une fois envoyé, le client doit le traiter. C'est minuscule, mais mesurable (voir les réponses ci-dessous)
Pour les déclencheurs, etc., le client recevra plusieurs "xx lignes affectées", ce qui provoque toutes sortes d'erreurs pour certains ORM, MS Access, JPA, etc. (voir les modifications ci-dessous)
Contexte:
La meilleure pratique généralement acceptée (je pensais jusqu'à cette question) est d'utiliser SET NOCOUNT ON
dans les déclencheurs et les procédures stockées dans SQL Server. Nous l'utilisons partout et un rapide google montre que de nombreux MVP SQL Server sont également d'accord.
MSDN indique que cela peut casser un .net SQLDataAdapter .
Maintenant, cela signifie pour moi que le SQLDataAdapter est limité au traitement CRUD tout simplement parce qu'il s'attend à ce que le message "n lignes affectées" corresponde. Donc, je ne peux pas utiliser:
- SI EXISTE pour éviter les doublons (aucune ligne affectée au message) Remarque: à utiliser avec prudence
- O NOT IL N'EXISTE PAS (moins de lignes que prévu
- Filtrer les mises à jour triviales (par exemple, aucune donnée ne change réellement)
- Faites tout accès à la table avant (comme la journalisation)
- Masquer la complexité ou la dénormalisation
- etc
Dans la question marc_s (qui connaît ses trucs SQL) dit de ne pas l'utiliser. Cela diffère de ce que je pense (et je me considère comme quelque peu compétent en SQL aussi).
Il est possible que je manque quelque chose (n'hésitez pas à souligner l'évidence), mais qu'en pensez-vous?
Remarque: cela fait des années que je n'ai pas vu cette erreur car je n'utilise pas SQLDataAdapter de nos jours.
Modifications après commentaires et questions:
Edit: Plus de réflexions ...
Nous avons plusieurs clients: l'un peut utiliser un C # SQLDataAdaptor, un autre peut utiliser nHibernate de Java. Celles-ci peuvent être affectées de différentes manières avec SET NOCOUNT ON
.
Si vous considérez les proc stockés comme des méthodes, alors c'est une mauvaise forme (anti-modèle) de supposer que certains traitements internes fonctionnent d'une certaine manière pour vos propres besoins.
Edit 2: un déclencheur brisant la question nHibernate , où SET NOCOUNT ON
ne peut pas être défini
(et non, ce n'est pas un doublon de cela )
Edit 3: Encore plus d'informations, grâce à mon collègue MVP
- KB 240882 , problème provoquant des déconnexions sur SQL 2000 et versions antérieures
- Démo du gain de performance
Edit 4: 13 mai 2011
Interrompt également Linq 2 SQL lorsqu'il n'est pas spécifié?
Edit 5: 14 juin 2011
Interrompt JPA, proc stocké avec des variables de table: JPA 2.0 prend-il en charge les variables de table SQL Server?
Edit 6: 15 août 2011
La grille de données SSMS "Modifier les lignes" nécessite SET NOCOUNT ON: Mettre à jour le déclencheur avec GROUP BY
Edit 7: 07 mars 2013
Détails plus approfondis de @RemusRusanu:
SET NOCOUNT ON fait-il vraiment une différence de performance