Closed proofrock closed 3 weeks ago
@proofrock this is a pretty old issue and it hasn’t been updated in a while, so I’m going to close it out. Hopefully you got it sorted.
As there was no answer, we couldn't sort it. In the end we used other tools. Is this tool abandoned?
@proofrock no, it just doesn’t get frequent updates. But what you ran into was a permissions issue that likely had a lot of local factors involved and not something that would require a fix to the procedure.
On the other hand, what we found is that basically to run the tool you'll have to be in the admin group. No possibility otherwise. This should be referenced in the documentation, as it's not something relevant to my installation only, it's perfectly reproducible for any Azure installation.
@proofrock sure, submit a documentation change PR where you think it would make sense. I don’t use SQLDB personally.
Hi, so sorry to come up with a permission issue, but this is a big pain point to which we couldn't find a solution yet, despite involving Microsoft support.
We have a number of Azure SQL databases, and we installed sp_whoisactive on them. As long as it's called by the db owner all is well. But if I create an user, assign roles/grants to it, and call the stored procedure with it, it fails.
More precisely, we tried this:
Of course something is overkill, here, but this is everything we tried. Then, executing
exec sp_whoisactive
from (e.g.) python gives:This is python, but every client we tried gives the same result, even management studio.
Could you help us, or spot something that we did wrong?
Best regards,
PS: the documentation cites
VIEW SERVER STATE
as a permission that is needed, but it cannot be granted on an azure db.