This is a plea to the DNN community to help me recover my database from a failed DNN upgrade.

 

I attempted a 4.9.5 upgrade to 5.6.0 and it failed. Because of the issues I removed all the 5.6.0 files from my website and replaced them with the original 4.9.5 versions. I then emailed my webhost to restore my SQL Database back to the last backup they had taken.

 

I was then informed by them that they only provide this service when they have a problem with their own equipment. Needless to say I was absolutely stunned by this revelation. I know they have a backup because I did check.

 

I have zero confidence in them providing any form of customer service, and come the weekend I will probably loose all hope of restoring my database because they only keep two weeks anyway.

 

So let that be a lesson to all those with webhosts. Don’t assume they have a backup that you can use!!!

 

I now need to try and somehow recover my site and re-attempt the upgrade, but this time stopping somewhere in-between 4.9.5 and 5.6.0. What do I have to do to make the database forget I tried to apply DNN 5.6? I know there are records within the version table, but what other things will I have to do?

 

As far as my DNN installation is concerned it’s pretty simplistic, with only HTML and FAQ modules being used, plus Forums.

 

Can anybody help me dig myself out of this hole, and perhaps suggest an alternative DNN web host that provides excellent customer service?

 

Many thanks

 

Steve

Hi William

The problems I had with the upgrade were around the Telerik.Web.UI.dll not being in the bin folder and a token mismatch in the web.config

I did fix these at the time, but when I went into the site I was unable to edit any html module content and going into modules to check version numbers also failed. It was at this point I decided to write off the upgrade attempt.

I read your comments about returning to 5.6.0 and trying to fix the problems at hand, and I'm guessing this is my best option. I did not keep the file system from 5.6.0 I always assumed I could just reapply it from the 5.6.0 upgrade package. Will I not be able to do this?

Alternativly can I not reverse the scripts that were applied? I don't need to get the site working again in 4.9.5 I just need to do enought to allow me to reupgrade, but this time stopping somewhere inbetween, before re-attempting the 5.6.0 upgrade.

Many thanks

Steve

Steve . . .

Without a backup of the files made after the failed upgrade to 5.06.00 (particularly web.config), any chance of getting a 5.06.00 site working is made all the more difficult. During an upgrade (especially when jumping through multiple versions), some changes are also made to configuration files, providers are installed or removed, module installations are upgraded, etc. so that the files and file structure is not necessarily the same as would be obtained from a re-application of the 5.06.00 upgrade package (which cannot be done now without being able to restore the 4.09.05 database).

It is not possible to reverse the SQL data provider scripts that were applied during the 05.06.00 upgrade. That is especially true due to very large number of changes in the database schema that have occurred since the 4.09.05 and early 5.x versions.

Although your options are even more limited without a backup of the file system following the failed 5.06.00 upgrade, I would attempt the following general outline of steps:

1. Create a localhost install of 5.06.00 and install the same version of all modules which existed on the production server. Ideally it should use the same version of IIS and ASP.Net that were running on the live server at the time of the failed upgrade.
2. Transfer critical sections of the backed up 4.09.05 web.config file to the new web.config file - these would include the machineKeys, objectQualifer, some appSettings but not connection strings as those will have to be delt with later.
3. Restore the backup of the 5.06.00 database over the newly created 5.06.00 database and if necessary re-add the same database user login as the new localhost site was using prior to the restoration.
4. Manually add a new portal alias for the localhost site to the PortalAlias table of the database
5. Resolve all issues that may result with the operation of the localhost site - likely there will be many.
6. Change the connection strings in web.config to those needed for the live server.
7. Backup both filesystem and database from localhost.
8. Restore both filesystem and database backups to live server.
9. Extensively test the migrated site and fix any remaining issues.

Be sure to check with your current host to verify that they will restore a database that was not originally created on their SQL server. GoDaddy and several other hosts will NOT.

The above procedure is not for the inexperienced and will be either very  time consuming and/or costly if you have the work done for you.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner