P.S.

If your fear of replication or otherwise updating multiple tables through the provider is because you don't want password information stored in the DNN database; you can get around storing the password in the tables.

Are your requirements that you cannot use replication (the services named replication, not theory).

Or are your requirements that you cannot have user information also stored in the DNN database?  It would seem a strange requirement if it was just that you didn't want the information (as a duplicate, maintained by the provider itself - not any form of replication) in the DNN database.

I mentioned to the project manager that you might be available to help out, but I got a luke-warm response.

Thanks very much. I'll let you know if we can take you up on the offer.

OK, so the more I look at this, the more questions I have. For instance, in the web.config file, there is the usual ASP.NET 2.0 membership section, and the default provider there is "AspNetSqlMembershipProvider". Then there is another "members" section that is a custom DNN section, and the "AspNetMembershipProvider" is set as the default there.

What gives? Why are there two member-related sections and two providers? Is the first one a standard ASP.NET 2.0 provider, while the second one is specific to DNN? Do I have to replace both? Any information about this would be greatly appreciated.

Thanks.