Moved DB, now Users can't login to my web app. 1

[NuJoizey]

This must be some kind of permissions issue, but I'm not sure where it is - and it's probably simple.

We are in the process of moving our DB app to some new servers.

I did a full backup of the Database on the old server and a restore on the new server.

I configured IIS and reinstalled my aspx files, and my web app is viewable and making a db connection - all the menus and gridviews etc. are being populated.

Everything seems to work well except that my app has code in it to recognize who is logged into the current session, and makes certain display choices based on that. If my app doesn't recognize a network user, it shows "not logged in". And so now it's doing that all the time, presumably because there is something amiss with the user logins.

2 things don't make sense.

1. I did the same backup/restore procedure about 3 months ago to create a test environment on a different server based on data in the production environment, and I didn't have this problem.

2. in visual studio, if I run my app in debug mode, it recognizes my user name and everything works normally.

So what does that all mean? where does the problem lie? is it a permissions/logins/user issue or not? I checked all the mappings and they seem to be right, pointing to the correct database, etc.

I did change the name of the Database from what it was on the old server. I figured that might have messed up stuff, so I tried

http://support.microsoft.com/kb/918992/

but the script failed saying that the accounts already exist.

What to do next????

 

[drtree]

Hi,

If possible, I would drop the database you moved and remove all of the user accounts that were created when you moved it. I had run into a similar problem in the beginning of the year when we were moving to a new server (and SQL 2005). Just doing the backup/restore didn't work for me because the users I needed transferred over weren't, so I ended up removing the database and all users and running through the process recommended by Microsoft. Here's what I ended up doing (in steps, so it might be easier to read):

1 Dropping the database I had moved over and deleting all of the logins associated with it on the new (destination) server
2 Running the script from the source server (which was running SQL 2000 in my case)
3 Saving the output of it to a .sql file which was generated in step 2
4 Run the sql script (from step 3) on the destination server
5 Restoring the database that I wanted to move

Alternatively, if you have Integration Services, you could run the Copy Database Wizard - this will copy logins for you and set them up. I hope that helps - some of the other experts out here might have some other (possibly better) advice for you, but that is what worked me....

Doc Tree

 

[NuJoizey]

thanks for your response drtree. i was able to figure this out, fortunately without having to go thru all that extra trouble.

What I have come to believe what was vexing me in this situation was that the old system configuration that I had become used to using (which was not set up by me) was the "hack" so to speak, but it took me a while to figure that out.

So when I started with a clean configuration, the "by design" behaviour looked like the anamoly, when it really wasn't.

I think I've straightened out the problem now, however, I will have to restore a couple more databases into the new environment.

I'm glad you reminded me of the Copy Database Wizard in Integration Services - perhpas that would be cleaner route for me to go in the remainder of my work on this migration.

cheers!