October 6, 2007 at 4:30 pm
I have an application that uses membership in asp.net. I originally created this application using the '/' as the app name. I read an article that suggested an application be 'named'. Silly me!! I thought I could just go into iis and change the name, and that would be all I need to do. Well, it seems that iis created a new app and now in my sql server database I have duplicate members and their membership information, including roles, but separate application names. looking back, I did notice that my roles seemed to 'disappear' in the asp.net configuration tool, so I thought I was re-adding the roles. I suppose that is when I duplicated everything.
My question: The default application when my clients sign up or login seems to be the original '/' as new people sign up for accounts. How can I safely delete the second 'named' app and not screw up membership info for the '/' app, and how can I safely rename the '/' app?
October 8, 2007 at 5:46 am
This isn't really about performance, it's about training - if you need to ask this type of question then you shouldn't be writing applications such as you describe. I'd suggest you get some training in SQL or at least buy some books and read them. please don't tell us you work for any major company or organisation ?
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
October 8, 2007 at 7:47 am
I don't work for any major companies, but I do have my own students. The site and database are my own. Right now as I study my tables, I see that the user IDs are different from the Membership table and the User table in my database. I am learning sql, and am seeking guidance to straighten out this little quirk.
October 8, 2007 at 9:20 am
yes I know you have to learn. but as I say this isn't a "quirk" it's a lack of understanding - and it doesn't belong under performance.
you could merge/export your data and clean it and re-import, then set constraints to avoid duplication in the future - if you have 100% duplicates then one way is to add a unique column ( usually an id column ) to the table so you can identify each row uniquely - then you can delete, update as required.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
October 8, 2007 at 10:11 am
I see. I am in the wrong forum. You are right... I didn't understand that as well. Thanks for your replies. I will look at your suggestions and move from this forum.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply