hismightiness wrote
Hmmm... I am thinking that I should not add profile settings... I was premature in saying that the exception was gone. When I put my classes back in place, there is indeed still a Foreign Key restraint exception happening in the same place, changing the status to "UnexpectedError" and sending me the exception (from an exception notification routine I have).
What happens that is good is:
- The DNN user is created.
- The e-mail is created and sent to the new user.
What happens that is bad is:
- The UserInfo object is not updated with the new UserID during this process within the providers (the real problem).
- The profile properties cannot then be updated without throwing the exception.
What I need to find out is:
- Where is the UserInfo object supposed to reassign the UserID property?
Upon investigating this, the DNN core team must know that this is the default behavior. I think that they do not intend on updating the UserInfo object until the user logs in.
Have you verified that your profile properties are added using the code you displayed? I believe that this "exception" is the intended behavior since the exeption is captured when updating a profile, but nothing is done with it.
SELECT
up.[ProfileID],up.[UserID],up.[PropertyDefinitionID],up.[PropertyValue],up.[PropertyText],
up
.[Visibility],up.[LastUpdatedDate]
FROM
[DATABASENAME].[dbo].[UserProfile] up
ORDER
BY up.[UserID] DESC, up.[PropertyDefinitionID]
Is your example occurring upon updating an existing user, a new user, or both? Do you use the membership provider to do it, or are you doing it with custom code? (I see in your example where you are assigning the profile information, but not where the UserInfo object comes from, or where it gets updated using the code.)