While this seems great at first, you have to be aware of the limitations it poses you. If you read the presentation it clearly says "...which means that the Profile property type needs to be compatible with the target database column".

So, your implementation of the profile would be tied to the data table structure. No way to provide different profiles for different portals, no way to have different profiles on different installations, ... since all have to be based on that table you have. For a specific use case this can be useful, for example, if you don't need all that extra features we provide. In that case I'm sure you can build your own dnn provider for that table provider you mention and replace the base provider in dnn.

I understand the default dotnetnuke provider was made generic so that it could support multiple portals on one server but many users have just one portal and want to use a clean sql database structure that is easy to expand and support.. and run reports on.

Do you know if anyone has tried to replace the default provider with the SqlTableProfileProvider?

If someone did this, what are the required fields that must be in the new provider table to support current DotNetNuke 4.3.2 users?

Is there a way to keep all the current functionality of the framework while adding custom fields (like an image field for a users jpeg photo) to a normal SQL table?

I think this would make a great whitepaper since many people are wondering how to tailor this great portal framework to their company or project and support sql data fields specific to their organization.

Thoughts?

SqlTableProvider links:

http://www.asp.net/sandbox/samp_profiles.aspx?tabindex=0&tabid=1

http://www.jbwebtech.net/Code/ProfileProvider/