Existují scénáře, kde je SET NOCOUNT ON povinné. Při navrhování vysoce výkonné střední vrstvy založené na asynchronním zpracování využívajícím fond vláken prostřednictvím metod BeginExecuteXXX SqlClient existuje velmi vážný problém s počty řádků. Metody BeginExecute jsou dokončeny hned první paket odpovědi je vrácen serverem. Ale když je vyvolán EndExecuteXXX, dokončí se to u požadavků bez dotazu po dokončení volání. Každá odpověď počtu řádků je odpovědí. Při zpracování i středně složitých procedur by se počet prvního řádku mohl vrátit za 5-10 ms, zatímco hovor je dokončen za 300-500 ms. Místo toho, aby odeslaný asynchronní požadavek zavolal zpět po 500 ms, zavolá zpět po 5 ms a poté se zpětné volání zablokuje v EndExecuteXXX na 495 ms. Výsledkem je, že asynchronní volání se dokončí předčasně a zablokují vlákno z fondu vláken ve voláních EndExecuteNonQuery. To vede k hladovění ThreadPool. Viděl jsem, že vysoce výkonné systémy zlepšily propustnost ze stovek hovorů za sekundu na tisíce hovorů za sekundu jednoduše přidáním SET NOCOUNT ON ve specifických scénářích.
Vzhledem k tomu, že pro zpracování na střední úrovni s vysokým rozsahem/vysokou propustností jsou jediným způsobem asynchronní volání, je NOCOUNT téměř povinným požadavkem.