Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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. </p> <p>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 <code>UserName</code> column from the <code>aspnet_User</code> table for this.</p> <p>Now if you want it to be always up to date then you have two options:</p> <ol> <li><p>Hacky and <strong>not advised</strong> 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 <code>dbo.aspnet_Membership_CreateUser</code>. Check your database for all aspnet membership stored procedures.</p></li> <li><p>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 <a href="http://www.mattwrock.com/post/2009/10/14/Implementing-custom-Membership-Provider-and-Role-Provider-for-Authinticating-ASPNET-MVC-Applications.aspx" rel="nofollow noreferrer">this one</a> and <a href="https://stackoverflow.com/questions/2771094/how-do-i-create-a-custom-membership-provider-for-asp-net-mvc-2">this one.</a></p></li> </ol> <p>Both options will need you to get familiar with the asp.net membership infrastructure.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload