Through a little experimentation, I discovered that rowcount requires "VIEW DATABASE STATE".
Methodology: Captured queries that SSMS runs and executed as a user with datareader permissions only. One in particular throws an error. After granting the permission, verified that rowcounts were now visible.
Honestly, sa or a disabled SQL Server account with absolutely minimum permissions is the best choice. As to why? Well, I could write out three or four paragraphs on that, or I can share my favorite article on What account should own the databases and why. A very thorough explanation covering all the bases. Highly recommended.
Here's a core excerpt: (...
Is there an underlying reason why databases cannot be owned by a secondary principal?
I'm not 100% certain of the reason for this restriction, though I suspect it has to do with the ability to impersonate (i.e. become) that SID. There are certain operations that can reach outside of the instance (e.g. to the OS, file system, etc) and the logic is usually ...
I am not sure what your question is. It seems you or the one who has asked you question are a bit confused between these terminologies.
SQL Server provides server-level roles to help you manage the
permissions on a server. These roles are security principals that
group other principals. Server-level roles are server-wide in their
Your question has already been answered in multiple comments and I hope you were able to solve them by now.
Let me try to summarize them for you in terms of roles, logins and users.
Logins and users: Logins and Users are basic security concepts in SQL
Server. They are often, and incorrectly, considered to be pretty much
one in the same so it is ...
Nowadays MySQL doesn't have a root password and instead uses the auth_socket plugin to verify the user that connected to the socket is the root user of the system. You could use this same technique to solve your problem if you are ok with having unix accounts for all your users, which opens up all kinds of possibilities e.g. easy binary file storage!
Sounds like DOMAIN\GroupName is a group and DOMAIN\user.name is a member of that group. This means that DOMAIN\user.name has access to SQL Server through that group. You have 2 options:
Create another group, let's say DOMAIN\NewGroupName and grant that group INSERT and UPDATE, then make DOMAIN\user.name a member of that group.
This is not the fastest ...
No postgresql does not inherit permissions in this fashion, Pretty much anything using the Create command sets the owner to the users that created it.
Use the GRANT command
Or after creating the tables set the Owner with Alter command
Create table Mytable (list of columns);
Alter table Mytable owner to producer;