1

I'm really unsure about how to handle this.

What I think I need is to have the usernames people register with ( through the default Provider ) to be copied to the UserName column of my other database, which has a junction table for a many:many relationship between User and Badge.

I've tried using SQL to copy the table over, but that's not really working out, as I don't know what table exactly I'm supposed to copy..

Any help would be dearly appreciated, and if more info is needed, please ask!

mktwo
  • 63
  • 1
  • 6
  • Could you provide some more info on why and when you need to sync? Isn't it better to insert/alter the data directly when the user registers or changes his username. – Martijn B Jan 13 '12 at 11:08
  • Well, as to the why, this is the only way I can think of making it work. Inserting the data at point of registering would be ideal, but I have no idea how to do that. – mktwo Jan 13 '12 at 11:47

2 Answers2

2

I'm not sure what your circumstances are, but as you're saying that the users are registered through the default Provider, I guess that the tables may have been generated by the aspnet_regiis tool?

If so, the users are stored in a table called aspnet_Users and the user names are in the column UserName.

I may have misinterpreted your question, but is this what you were asking for?

Christoffer
  • 2,125
  • 15
  • 21
0

This really depends on your requirements which aren't really clear. If you always want your data to be up to date in your other database then syncing by copying the whole table isn't the way to go.

If you don't mind that you get the usernames on a later moment in time then syncing is the way to go. For example if you use the other database for BI purposes only, then a simple job for example in the night will do fine. Like Christoffer said you will need the UserName column from the aspnet_User table for this.

Now if you want it to be always up to date then you have two options:

  1. Hacky and not advised by me. Extend the stored procs which are called by the default membership provider by also updating the other database. For example you could alter dbo.aspnet_Membership_CreateUser. Check your database for all aspnet membership stored procedures.

  2. Implement your own membership provider which calls your own stored procedures or the default stored procedures + additional queries for updating the other database. This one is the most work and would be my choice. For examples of custom implementations see this one and this one.

Both options will need you to get familiar with the asp.net membership infrastructure.

Community
  • 1
  • 1
Martijn B
  • 4,065
  • 2
  • 29
  • 41