you have to modify your source (query) and get the Count of users and grouping them on basis of user roles to yield the desired dataset and then bind it with grid.
Some query like one below would do. Note this is only a rough prototype:
select count(userid) as User_Count , user_role for user_table group by user_role.
If you're using the standard membership features, then you can do this with a small amount of code. I'd create a custom class to hold the results, instead of a table/dataset. For example, the class could be:
I'm not familiar with get set. I've placed the first portion into a cs file and the rest into backcode but I'm getting the error The type or namespace name 'RoleAndUser' could not be found (are you missing a using directive or an assembly reference?
The {get;set;} thin is an automatic property; it's just a property but one for which .NET manages the backing variable, rather than you creating it yourself. It's just a shortcut (less typing) and makes the code look tidier.
the new .cs file you created will have a 'namespace' at the top. Eg:
namespace MyProject
{
...
In the code file where you are using this, make sure you have a using statement for that namespace. Eg:
using MyProject;
You'll see all the other namespaces at the top of the file.
Namespaces are just a way of logically grouping code.
Marked as answer by laazsx on Feb 07, 2012 10:48 AM
Actually, the most efficient way to do this is to bypass the API entirely and hit the database directly, that way you don't iterate at all; it's a single call. This query will work:
SELECT RoleName, COUNT(*) As NumberOfUsers
FROM aspnet_Roles r
INNER JOIN aspnet_usersInRoles uir ON r.RoleID = uir.RoleId
GROUP BY RoleName
ORDER BY RoleName
You can then load this into a DataSet or use a DataReader to read it directly.
You could do that yes, but it would not be a reusable way of doing things. The provider itself can change, people can have a different membership schema. What do you do then ? Go and write another stored procedure ?
I'd let the membership deal with stuff like this. This is not really a time consuming issue, unless you iterate over every single user :).
No, it's only portable within the default schema. But then if that's never (never say never?) going to change, I don't see it as a problem if documented.
laazsx
Member
277 Points
157 Posts
how to get roles with number of users in them
Feb 03, 2012 12:08 AM|LINK
Hi,
How am I able to get the number of users in a role together with the role itself in a gridview?
I'm already able to get all the roles, and how many users are there in a specific role but not together in a single dataset.
Andrew
Ebad86
Member
202 Points
37 Posts
Re: how to get roles with number of users in them
Feb 03, 2012 06:18 AM|LINK
you have to modify your source (query) and get the Count of users and grouping them on basis of user roles to yield the desired dataset and then bind it with grid.
Some query like one below would do. Note this is only a rough prototype:
select count(userid) as User_Count , user_role for user_table group by user_role.
Dave Sussman
All-Star
37716 Points
5005 Posts
ASPInsiders
MVP
Re: how to get roles with number of users in them
Feb 03, 2012 08:10 AM|LINK
If you're using the standard membership features, then you can do this with a small amount of code. I'd create a custom class to hold the results, instead of a table/dataset. For example, the class could be:
Then your code could be:
This just loops through the roles and users, adding to a list of the container class, which is then bound to a grid.
laazsx
Member
277 Points
157 Posts
Re: how to get roles with number of users in them
Feb 07, 2012 10:34 AM|LINK
Hi,
I'm not familiar with get set. I've placed the first portion into a cs file and the rest into backcode but I'm getting the error The type or namespace name 'RoleAndUser' could not be found (are you missing a using directive or an assembly reference?
Andrew
Dave Sussman
All-Star
37716 Points
5005 Posts
ASPInsiders
MVP
Re: how to get roles with number of users in them
Feb 07, 2012 10:42 AM|LINK
The {get;set;} thin is an automatic property; it's just a property but one for which .NET manages the backing variable, rather than you creating it yourself. It's just a shortcut (less typing) and makes the code look tidier.
the new .cs file you created will have a 'namespace' at the top. Eg:
namespace MyProject
{
...
In the code file where you are using this, make sure you have a using statement for that namespace. Eg:
using MyProject;
You'll see all the other namespaces at the top of the file.
Namespaces are just a way of logically grouping code.
laazsx
Member
277 Points
157 Posts
Re: how to get roles with number of users in them
Feb 07, 2012 10:48 AM|LINK
Thanks for the clarification! Got it to work now.
Andrew
eidand
Member
522 Points
146 Posts
Re: how to get roles with number of users in them
Feb 07, 2012 10:57 AM|LINK
Dave Sussman
All-Star
37716 Points
5005 Posts
ASPInsiders
MVP
Re: how to get roles with number of users in them
Feb 07, 2012 12:58 PM|LINK
Actually, the most efficient way to do this is to bypass the API entirely and hit the database directly, that way you don't iterate at all; it's a single call. This query will work:
SELECT RoleName, COUNT(*) As NumberOfUsers
FROM aspnet_Roles r
INNER JOIN aspnet_usersInRoles uir ON r.RoleID = uir.RoleId
GROUP BY RoleName
ORDER BY RoleName
You can then load this into a DataSet or use a DataReader to read it directly.
eidand
Member
522 Points
146 Posts
Re: how to get roles with number of users in them
Feb 07, 2012 01:08 PM|LINK
You could do that yes, but it would not be a reusable way of doing things. The provider itself can change, people can have a different membership schema. What do you do then ? Go and write another stored procedure ?
I'd let the membership deal with stuff like this. This is not really a time consuming issue, unless you iterate over every single user :).
Dave Sussman
All-Star
37716 Points
5005 Posts
ASPInsiders
MVP
Re: how to get roles with number of users in them
Feb 07, 2012 01:24 PM|LINK
No, it's only portable within the default schema. But then if that's never (never say never?) going to change, I don't see it as a problem if documented.