Hello Lee and others,

I have a huge dilemna to throw out to this community that has been a big challenge for me in which I have a diagnosis but not a solution.

Here is the issue When our website first went up berkshires.org back a year or two ago dotnetnuke 4.5.1 was installed under the mssql 2000 database.  This framework has been a little slow but efficient. taking 2 to 3 seconds a click to querey pages in the database.  However now I am trying to migrate the database to 2005 been trying to do so for a few weeks now but now understand the real problem that is at hand.  When migrating to 2005 via backup and restore tools I find that dotnetnuke crawls like a snail taking almost 2 minutes to laod the home page and than over a minute a piece to get to any other page on the site weather it be login, or any other info be it logged in as admin, editor or simply being an annonymous user who isn't logged in at all.

I thought at first this issue stemmed from the fact I was using windows xp pro for developing or attempting to set up a development environment which I was advised was a wrong decision being advised rather to opt for say windows 2003 server.  At any rate I opt to go ahead and use another account on the remote host that housed the production site in order to house the development site for now blaming the problem on software in particular windows xp pro. 

What I learned shocked me.  You see instead of it now being fast by restoring the mssql 2000 database on a remote sql 2005 database it went the same speed as it did on my local computer taking approximately a minute and a half a click.  This was intolerable to me so I decided as part of my troubleshooting I would go ahead download an evaluation of mssql 2000 and try to see what would happen if I restored mssql 2000 back up from the remote server to my local computer using the same sql 2000 environment.

What I found was astounding apparently when I restored this backup to the same version of mssql that it was backed up from I saw very VERY significant speed differences we are talking that it went from taking a minute and a half a click to a second maybe 2 to querey each page.  Threrefore what I discovered was that when a sql 2000 backup housing the dotnetnuke web application was backed up and restored on a mssql 2000 server it was very efficient but when restored on the next version up sql 2005 it was very sluggish having a difference of 1 minute and 30 seconds lag time.

So the problem was diagnosed that apparently a dotnetnuke installation of 4.5.1 that was installed on a mssql 2000 server has issues rendering pages effeciently from the database when restored or migrated to the sql 2005 environment.  As you can imagine I am perplexed because I don't understand why simply backing up sql 2000a nd restoring it onto sql 2005 would cause sug lag time issues.  I am almost certain the problem is do to the fact dotnetnuke was installed initially on 2000 and transported or migrated to 2005 and somewhere down the line things went awry concerning efficency what I don't understand is if dotnetnuke 4.5.1 is responsible for this issue or if it is something in the sql 2005 routine that doesn't colaberate well with a dotnetnuke 4.5.1 installation on sql 2000 I am not sure which one it is.

I have been hesitant to upgrade to 4.7.1 at least the live site as I would like to test things out in a development environment first to make sure the upgrade wouldn't blow apart the database before deciding to to upgrade. 

So the question is have any of you experienced this same situation and do you think it is the dotnetnuke 4.5.1 that is behind this issue or is it something to do witht he way new ms sql 2005 interacts with dotnetnuke info from an older server.?  This is where I am at wondering if I am going to be forced to be locked down to mssql 2000 until host companies really start supporting the new mssql 2008 or if it is just a matter of either upgrading dotnetnuke or figuring out another way of migrating dotnetnuke into 2005 besides the simple backup and restore routines.

Thanks for your help,

Bo

Even in the face of evidence, I'd be cautious in accepting that explanation. Mainly, I don't think that it makes sense. I think that there is something else going on. Unfortanately, I don't know what it is.

What you might do is (1) make sure that the transaction logs are cleaned out and (2) that your database indexes get rebuilt. Both of those things can be done with the SQL Server Management tool.

Resolved. I hadn't gotten a chance to look at your reply Joe until I did the upgrade on the development end of things but not the live end.

Last night at 12:00 AM I found my solution. In deed it was something at least in part to do with the application because when I updated my sql 2000 database with dnn 4.8 successfully and then migrated it to sql 2005 express rewiring the web.config file to reflect the new connection strings I found the website to be almost as fast as I expected.

It seemed like occassionally I got some lag but all in all I was moving right along in the site getting querey results within a couple seconds at the most not minutes.

I really can't explain why an upgrade to 4.8 would in fact make the difference in terms of efficency after migration but in my case it seemed to. I didn't do the two step process on the development side of things and didn't have any apparent issues though I hadn't got to the point of testing third party modules to see how the change effected them.

I will say that when I tried to put this up to a remote developers site by pshing up the dnn files and premade web.config files to reflect the upgrade with the remote connection string I did recieve some exception errors.

I don't know if these were do to the fact that I was attempting to update an already migrated installation (that was as slow as molasses) to 4.8 in hopes I could bypass having to upload the already working and upgraded database file or if it was something else.

Either way I ended up having to opt to upload the working database that I backed up from sql 2005 express that was efficient in hopes this would stop the exception error.

Only time will tell as the shared hosting company I use happens to have some kind of bug in their restore utility that makes it impossible for me to use it to restore my own database so their dba who proably is running like a chicken has always got to do the work for me.

I guess this bug only effects those who have a backed up sql 2000 database and want to restore it onto a sql 2005 database or those who originally started with a sql 2000 database backup opposed to a 2005 apparently their is a lag time of 30 to 60 seconds when this occurs timing out the database and choking the restore process.

Anyway thanks for everything and I will keep you posted as to how this goes. I read your post by the way on the two step upgrade and I was wondering what kinds of errors should I look for now that I have 4.8 on the dev side of things since I didn't do the 4.6.2 to 4.8 upgrade thing. What issues can pop up when going directly from say 4.5.1 to 4.8 opposed to doing it in two step manner as in 4.6.2 to 4.8 etc... Thanks for chatting and helping

Bo