The purpose of this story was to use the new user fields and fix the two pages that used the old Profile system — create user and view profile. As it turns out, this story actually became fixing the problems introduced in the last story, which I found out soon enough.
In the last story I chose to add new fields to the existing ASP users table. While this seemed like an innocent thing to do, as it turns out it’s probably not the best idea, because the way the whole CreateUserWizard template is set up, it is expecting certain fields with certain names to be in the create user form, and automatically add insert these into the database.
The bad thing about automatic is that it does a poor job of customization. In my case, I was trying to add a first and last name field, an alias, and an about me field. Although the last was optional, the other 3 were not, which meant that I could just rely on the system to do an insert for me, because it needed some value. But the CreateUserWizard is already set up to do the insert automatically, and doesn’t seem to allow user intervention.
Again, ASP simplifying things helps you if you are doing it exactly that way, but continually gets in the way if you try to do something different. Very frustrating.
Anyhow, I had to backtrack and undo the fields I added, and instead make a new table, UserInfo, which now stores the new data. This was doubly irritating because I had to move the test data I had painstakingly set up in the last story, into the new table. I thought it would be easy to just copy entire columns of data from table to table, but alas, it appears as though you have to do it one data value at a time. Argh. Today was not a good day.
Here’s the new DB structure.
