OK, same thing again (single installation, 2 portals, works in 1, doesn't in the other).

Without looking for ilegal characters in the username or something (if that was even allowed in a point release), the most obvious difference among the portals that work and the portals that don't is the number of user accounts.

User Accounts number in the thousand where this isn't working, yet works in those portals on the same DNN install that only have a few hundred users.

Does that mean that it's caused by:

• a (realtively) higher number of accounts - thousands versus hundreds?
• because of the increased number of accounts, there's an illegal character in something like the username that crashes the retrieval/display of records?

Any input appreciated. Maybe the folks that are experiencing this error can chime in with their experience? It's not so much a DNN-wide bug, but rather unique to particular portals.

I am beginning to suspect that the problem is orphaned user data. I had a similar error running DNN Masters User Import Manager and turned to their forums for help; http://www.dnnmasters.com/support/forum.htm?forumid=37&threadid=1961&scope=posts&threadpage=2 .  However, even after running the script suggested, I have the error! I also have over a thousand users on this portal!

If some data between the various "user" tables gets out of whack it would seem that this kind of issue could be caused. We need the help of a db wizard here, I am not worthy.

This is the script that Chris posted but he says it was created by John Mitchell of Snapsis fame, maybe John can help here too!

DECLARE @UserName varchar (50)

--get a cursor to hold all the orphaned users
--that are in aspnet_Users table that are not in the DNN Users table
DECLARE users_cursor CURSOR FOR
SELECT au.UserName FROM aspnet_Users au 
LEFT OUTER JOIN Users u on au.UserName = U.UserName 
WHERE U.UserName is null

OPEN users_cursor

-- Perform the first fetch.
FETCH NEXT FROM users_cursor INTO @UserName

-- Check @@FETCH_STATUS to see if there are any more rows to fetch.
WHILE @@FETCH_STATUS = 0
BEGIN
--delete the user from all the aspnet_* tables that it may be in
--one at a time to avoid referrential integrity constraints

delete aspnet_Membership where UserId = 
(select am.UserId from aspnet_Membership am inner join aspnet_Users au on am.UserId = au.UserId
where au.Username =@UserName)

delete aspnet_Profile where UserId = 
(select ap.UserId from aspnet_Profile ap inner join aspnet_Users au on ap.UserId = au.UserId
where au.Username =@UserName)
delete aspnet_UsersInRoles where UserId 
in (select uir.UserId from aspnet_UsersInRoles uir inner join aspnet_Users au on uir.UserId = au.UserId
where au.Username =@UserName)

delete from aspnet_Users where Username =@UserName 

FETCH NEXT FROM users_cursor INTO @UserName
END

CLOSE users_cursor
DEALLOCATE users_cursor
GO

The store procedue to get the list of users by role name is  "dbo.GetUsersByRolename".  This store procedute takes two parameters: PortalID and RoleName.

Log in as Host and go to menu Host >> SQL.  Run this store procedure against the role name that caused the error. 

Example script:  GetUsersByRolename 0, 'Administrators'

Does the store procedure work?  If there is error, please post it here.

STORE PROCEDURE dbo.GetUsersByRolename

CREATE PROCEDURE dbo.[GetUsersByRolename]

 @PortalId int,
 @Rolename nvarchar(50)

AS

SELECT    
  U.UserID,
  UP.PortalId,
  U.Username,
  U.FirstName,
  U.LastName,
  U.DisplayName,
  U.IsSuperUser,
  U.Email,
  U.AffiliateId,
  U.UpdatePassword
 FROM dbo.UserPortals AS UP
   RIGHT OUTER JOIN dbo.UserRoles  UR
   INNER JOIN dbo.Roles R ON UR.RoleID = R.RoleID
   RIGHT OUTER JOIN dbo.Users AS U ON UR.UserID = U.UserID
  ON UP.UserId = U.UserID 
 WHERE ( UP.PortalId = @PortalId OR @PortalId IS Null )
  AND (R.RoleName = @Rolename)
  AND (R.PortalId = @PortalId OR @PortalId IS Null )
 ORDER BY U.FirstName + ' ' + U.LastName