Extending ASPNETDB

malie22001 · December 15th, 2011, 12:48 PM

Hi Imar,

Thank you very much for your time in this forum.

In the book I saw that you used the UserName from the ASPNETDB database. Now I have a database that has a Customer, an Address, an Appointment, and a Staff table. I want to create a relationship between my tables (Customer and Staff) and the aspnet_Users and aspnet_Membership tables.

What I want to do is have a UserID column in each of my tables as a foreign key to those two aspnetdb tables.

The thing is I want to collect more information like contactNo, address, etc from the customers and I want to be able to query the tables and return a single value.

The thig is I do not see any way in the System.Web.Security namespace to access the UserID from those tables.

Is there another way or can a relationship be made between those tables?

Imar · December 16th, 2011, 04:10 PM

Hi there,

Quote:

The thig is I do not see any way in the System.Web.Security namespace to access the UserID from those tables.

Not sure what you mean with this. You can get the user name from User.Identity as explained in the book, which you can then use to query your own tables. If that's not what you mean, can you elaborate on what you're looking for?

Cheers,

Imar

malie22001 · December 16th, 2011, 05:51 PM

Hi Imar,

Thank you for responding to my post. What I meant is that in the book, you used the UserName.What I want to do is put a UserId column in my table as the foreign key and create a relationship between my table and the aspnetdb users or membership table.

Is it advisable?

Second, how do I get the UserId when the user signs up. I am using the hand coded method and the EF model.
Thank you once again...

Imar · December 17th, 2011, 05:21 AM

Hi malie22001,

There are a few ways to uniquely identify a Membership user. The official recommendation by Microsoft is to use a combination of the UserName and the application name (which you set in the web.config file on the Membership and other configuration elements). You should store both in your custom tables.

As an alternative, you can store the user's unique ID, a GUID in the case of the standard SqlMembershipProvider, which you can get by calling Membership.GetUser().ProviderUserKey.

Microsoft recomends against using the ProviderUserKey as its internal implementaton which *might* change in the future. However, it hasn't changed since the first release of Membership so you're probably safe if you use it.

Cheers,

Imar