This project is read-only.


Membership.CreateUser uses wrong [dbo].[users] table


When executing
            Membership.CreateUser(model.UserName, model.Password, model.Email, null, null, true, null, out createStatus);
I'm getting an exception. Digging a bit deeper reveals that this query is sentto the db:
exec sp_executesql N'SELECT
[Limit1].[ApplicationId] AS [ApplicationId],
[Limit1].[UserId] AS [UserId],
[Limit1].[UserName] AS [UserName],
[Limit1].[IsAnonymous] AS [IsAnonymous],
[Limit1].[LastActivityDate] AS [LastActivityDate]
[Extent1].[ApplicationId] AS [ApplicationId], 
[Extent1].[UserId] AS [UserId], 
[Extent1].[UserName] AS [UserName], 
[Extent1].[IsAnonymous] AS [IsAnonymous], 
[Extent1].[LastActivityDate] AS [LastActivityDate]
FROM  [dbo].[Users] AS [Extent1]
INNER JOIN [dbo].[Applications] AS [Extent2] ON [Extent2].[ApplicationId] = [Extent1].[ApplicationId]
WHERE ((LOWER([Extent2].[ApplicationName])) = @appName) AND ((LOWER([Extent1].[UserName])) = @userName)
) AS [Limit1]',N'@appName nvarchar(4000),@userName nvarchar(4000)',@appName=N'/',@userName=N'gv'
IMHO FROM [dbo].[Users] should be [aspnet].[Users], and probably [dbo].[Applications] must be [aspnet].[Applications] as well?


jimmyzimms wrote Feb 20, 2012 at 8:01 PM


We're trying to attempt to recreate the issue on our systems at the moment. It will be helpful to get some additional information:
  1. Which release are you targeting? (SQL or Azure? releases 49381 and 50162 respectively)
  2. You are executing this TSQL directly or indirectly (such as via a LINQ Query Provider or the Membership Provider types?)
One thing to note here is your captured TSQL here (thanks for that btw!) has particular syntax style that is very reminicent of Entity Framework. Are you executing the underlying DB code via imported functions/sprocs/tables/views? If so it actually appears that your mapping is not correct.

Another thing to confirm is that if you are instead leveraging the Membership Provider C# API, that you are correctly configuring the system to support the compiled custom Sql Provider we ship (System.Web.ApplicationServices.Alternate aseembly) as opposed to the version shipped and loaded by default by the .Net Framework.

Feel free to send a message back with a sample or other information so that we can help you further.


gverelst wrote Feb 20, 2012 at 10:00 PM

Hi Jimmy,

It seems that I have been too fast to create this issue.
I'm using MVC4, which is using the Universal providers. I had created the db objects from your scripts, but they don't match with the UP.
OTOH, I didn't manage to get your providers (alternate) working, so a bit of documentation may be helpful here (but that would be another issue ;-)
I'm using the UP now and all is working!

Thanks anyway for your swift response!

jimmyzimms wrote Feb 20, 2012 at 10:49 PM

Ahh glad to hear that it's just configuration here. You are correct that there's a large amount of assumed knowledge on ASP.Net configuration to leverage the providers that work with our updated schema. Here's a helpful link to get started with ( While this is specifically for 2.0 the configuration elements remained the same (just the version numbers, where 4.0 specific, have been updated).

I'll add a WI to enhance the documentation to provide the very minimal configuration required to spark up our versions as well as say a small sample site that is configured.

jimmyzimms wrote Feb 20, 2012 at 10:58 PM

Closing issue for now. We've created task 10411 for creating better docs and sample applications that should prevent this misunderstanding in the future.

wrote Feb 1, 2013 at 1:04 AM

wrote May 1, 2013 at 9:45 PM

wrote Jun 6, 2013 at 1:21 AM