@@ROWCOUNT Support
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(rowcount) AS rowcount
FROM sys.dmpdwsqlrequests
WHERE rowcount <> -1
AND request_id IN
( SELECT TOP 1 request_id
FROM sys.dm_pdw_exec_requests
WHERE session_id = SESSION_ID()
AND resource_class IS NOT NULL
ORDER BY end_time DESC
)
Luke
shared this idea
4 comments
-
Anonymous
commented
this is a problem... need @@ROWCOUNT
-
Paweł
commented
Please enable @@ROWCOUNT
-
Mike LaRue
commented
I've encountered the same situation described earlier where fast overwriting of information in the sys.dm_pdw_request_steps DMV causes the row_count to age off before it can be read by the workaround.
If it is not possible to implement the @@ROWCOUNT system function in Azure data warehouse in the near term, could the capacity of the sys.dm_pdw_request_steps and sys.dm_pdw_exec_requests be increased to double the current limits in the interim?
-
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...
Simon