With the release of DNN 7.3.0 this week, it was time for me to get my sites upgraded. I upgraded most of the sites without any issues, but wanted to point out a few errors that I received on sites, and how I resolved them.

The very first upgrade I did started out bad, it was for this site, and while the upgrade was 100% successful, as soon as I tried to load the site I got a generic 500 error. Accessing the site from the webserver gave me a little more information, seen below, but not much.

I was upgrading a customer's website this evening, in a test environment thankfully, and ran into a problem. The upgrade appeared to run successfully, minus one little issue with a primary key (in the 6.0.0 script).

But after running the upgrade, the website wouldn't load. I kept getting an error in Chrome, and then finally started getting 503 errors as the server shut down the application pool completely.

If you have a DotNetNuke website that has been around for a while, you likely have a large number of pages on the site. Many of those pages likely have individual Skins (themes) applied to them. When there is a skin defined at the Page level in DNN, that setting overrides the skin that is defined at the website level, meaning, if you change the skin at the Website level, it would not change the look and feel of any of the pages with their own skins defined.

So today I was getting impatient with some of the load times on SCCAForums.com, so I decided to run the SQL profiler on the database to see if there were any suggested improvements to speed it up. I ran the tuning wizard and it came up with a suggest that would be a 93% improvement, sold, lets run the script! Fast forward, an hour later, when I go to make a post on the server and boom it fails. WTF? "Hey Dave, can you post and see if my ban on your account works". He gets the same error. Not good. Anyways, SQL server's tuning wizard created a view, and when applying an index to that view it setup a requirement for ARITHABORT ON to be set when inserting into the cs_posts table. It took me a while to fix it, but I think everything is back up and running now. I removed the index on the view that was created :( Lesson learned, don't just execute random SQL on your database, even if SQL server suggested it!