Please enable @@ROWCOUNT?
Furthermore considering that we cannot switch NOCOUNT on, then why should it be such a secret/coded mission to track the number of rows affected by the most recent snippet of code? The proposed work-around seems onerous and doesn't always work (for dynamic SQL) yet my query window still knows and always-prints the fact that it returned 15 rows to me, for example, so why can we not leverage this elementary information inside the selfsame query (?):
SELECT SUM(row_count) AS row_count
WHERE row_count <> -1
AND request_id IN
( SELECT TOP 1 request_id
WHERE session_id = SESSION_ID()
AND resource_class IS NOT NULL
ORDER BY end_time DESC
Thanks for your suggestion. We are looking into this scenario for a future release. 10697269
Simon Whiteley commented
We're currently hitting an issue with this one - we're using the workaround query you've got above you rowcount logging, but we're running lots of procedures in parallel which each kick off a stats rebuild. The stats rebuild FLOODS the sql_requests table and forces to be aged out before we've had a chance to get their rowcount.
A rowcount solution that is susceptible to a race condition isn't a good solution especially, as mentioned, the query window displays the rows updated so the metadata must be available somewhere!
Hoping this gets sorted soon...