Има сценарии, при които SET NOCOUNT ON е задължително. При проектиране на средно ниво с висока производителност, базирано на асинхронна обработка, използваща пула от нишки чрез методите BeginExecuteXXX на SqlClient, има много сериозен проблем с броя на редовете. Методите BeginExecute завършват веднага щом първи пакетът с отговор се връща от сървъра. Но когато се извика EndExecuteXXX, това завършва при заявки, които не са заявки, когато извикването приключи. Всеки отговор на брой редове е отговор. При обработка дори на умерено сложни процедури броят на първия ред може да се върне след 5-10 ms, докато повикването завършва след 300-500 ms. Вместо подадената асинхронна заявка да извика обратно след 500 ms, тя извиква обратно след 5 ms и след това обратното извикване блокира в EndExecuteXXX за 495 ms. Резултатът е, че асинхронните извиквания завършват преждевременно и блокират нишка от пула на нишките в извикванията EndExecuteNonQuery. Това води до гладуване на ThreadPool. Виждал съм системи с висока производителност, които подобряват пропускателната способност от стотици повиквания в секунда до хиляди повиквания в секунда просто чрез добавяне на SET NOCOUNT ON при конкретни сценарии.
Като се има предвид, че за високомащабна/високопроизводителна обработка на средно ниво асинхронните повиквания са единственият начин, NOCOUNT е почти задължително изискване.
