@@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
7 comments
-
Roopkumar
commented
This is absolutely necessary variable. As I need the count of deletes, now before deleting the data I have to do select count(1) which is resource consuming.
-
Paul Wehland
commented
@@rowcount returns int datatype. We also need ROWCOUNT_BIG() which returns bigint datatype.
-
Anonymous
commented
Hello! I'm using a workaround in Synapse Analytics to get the row count of inserts/ updates in some stored procedures, but I often get incorrect number of rows returned. So I am really hoping that a simple and reliable alternative to @@ROWCOUNT will be available soon!
-
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