Der er scenarier, hvor SET NOCOUNT ON er obligatorisk. Når man designer et højtydende mellemniveau baseret på asynkron behandling, der udnytter trådpuljen via SqlClients BeginExecuteXXX-metoder, er der et meget alvorligt problem med rækkeantallet. BeginExecute-metoderne fuldføres, så snart den første svarpakken returneres af serveren. Men når en EndExecuteXXX påkaldes, fuldføres dette på ikke-forespørgsler, når opkaldet er afsluttet. Hvert rækketællingssvar er et svar. Ved behandling af selv moderat komplekse procedurer kan det første rækketal komme tilbage efter 5-10 ms, mens opkaldet afsluttes på 300-500 ms. I stedet for at få den indsendte async-anmodning til at ringe tilbage efter 500 ms, ringer den tilbage efter 5 ms og derefter blokerer tilbagekaldet i EndExecuteXXX i 495 ms. Resultatet er, at asynkrone opkald afsluttes for tidligt og blokerer en tråd fra trådpuljen i EndExecuteNonQuery-kaldene. Dette fører til ThreadPool-sult. Jeg har set højtydende systemer forbedre gennemstrømningen fra hundredvis af opkald pr. sekund til tusindvis af opkald pr. sekund blot ved at tilføje SET NOCOUNT ON i specifikke scenarier.
I betragtning af at asynkrone opkald er den eneste vej at gå for høj skala/høj gennemløbsbehandling på mellemniveau, er NOCOUNT stort set et obligatorisk krav.