Zainspirowany tym pytaniem, gdzie istnieją różne widoki na SET NOCOUNT ...
Czy powinniśmy używać SET NOCOUNT ON dla SQL Server? Jeśli nie, dlaczego nie?
Co robi Edytuj 6, 22 lipca 2011 r
Pomija komunikat „wpływ xx wierszy” po dowolnym DML. Jest to zestaw wyników i po wysłaniu klient musi go przetworzyć. Jest mały, ale mierzalny (patrz odpowiedzi poniżej)
W przypadku wyzwalaczy itp. Klient otrzyma wiele „wpływających wierszy xx”, co powoduje wszelkiego rodzaju błędy dla niektórych ORM, MS Access, JPA itp. (Patrz zmiany poniżej)
Tło:
Ogólnie przyjętą najlepszą praktyką (myślałem do tego pytania) jest stosowanie SET NOCOUNT ON
w wyzwalaczach i procedurach przechowywanych w SQL Server. Używamy go wszędzie, a szybkie google pokazuje wiele zgodnych MVP programu SQL Server.
MSDN twierdzi, że może to uszkodzić SQLDataAdapter .net .
Teraz oznacza to dla mnie, że SQLDataAdapter ogranicza się do całkowicie prostego przetwarzania CRUD, ponieważ oczekuje, że komunikat „n wierszy dotkniętych” zostanie dopasowany. Nie mogę więc użyć:
- JEŚLI ISTNIEJE, aby uniknąć duplikatów (komunikat nie ma wpływu na wiersze) Uwaga: należy zachować ostrożność
- GDZIE NIE ISTNIEJE (mniej wierszy niż oczekiwano
- Filtruj trywialne aktualizacje (np. Żadne dane w rzeczywistości się nie zmieniają)
- Czy wcześniej uzyskać dostęp do tabeli (np. Logowanie)
- Ukryj złożoność lub denormlisation
- itp
W pytaniu marc_s (który zna się na jego SQL-ach) mówi: nie używaj go. Różni się to od tego, co myślę (i uważam się za nieco kompetentnego w SQL).
Możliwe, że coś mi umknęło (nie krępuj się wskazać oczywiste), ale co tam myślicie ludzie?
Uwaga: minęły lata, odkąd widziałem ten błąd, ponieważ obecnie nie używam SQLDataAdapter.
Edycje po komentarzach i pytaniach:
Edycja: więcej myśli ...
Mamy wielu klientów: jeden może używać C # SQLDataAdaptor, inny może używać nHibernate z Java. Można to zmienić na różne sposoby SET NOCOUNT ON
.
Jeśli traktujesz przechowywane procy jako metody, to zła forma (anty-wzorzec) zakłada, że pewne wewnętrzne przetwarzanie działa w określony sposób na twoje własne potrzeby.
Edycja 2: wyzwalacz przerywający pytanie nHibernate , gdzie SET NOCOUNT ON
nie można ustawić
(i nie, to nie jest duplikat tego )
Edycja 3: Jeszcze więcej informacji, dzięki mojemu koledze z MVP
- KB 240882 , problem powodujący rozłączenia w SQL 2000 i wcześniejszych wersjach
- Demo zwiększenia wydajności
Edytuj 4: 13 maja 2011 r
Łamie także SQL Linq 2, gdy nie jest określony?
Edytuj 5: 14 czerwca 2011 r
Łamie JPA, przechowywane proc ze zmiennymi tabel: Czy JPA 2.0 obsługuje zmienne tabel SQL Server?
Edytuj 6: 15 sierpnia 2011 r
Siatka danych „Edycja wierszy” SSMS wymaga ustawienia USTAW NOCOUNT: Zaktualizuj wyzwalacz za pomocą GROUP BY
Edycja 7: 07 marca 2013
Bardziej szczegółowe informacje z @RemusRusanu:
Czy USTAW NOCOUNT naprawdę robi tak dużą różnicę w wydajności