Saturday, July 04, 2009Login    
Will Strohl - The Mighty Blog - RSS Feed

 Most Popular Entries 
 Blog Tag Cloud 
 Blog Roll 
 Search Blog 
 Blog Archive 

 


WebHost4Life Standard
 The Mighty Blog 
Dec26

Written by:Will Strohl
12/26/2008 

Every once in a while, I face an error installing DotNetNuke that completely frustrates me.  It is only because it forces me to start over with the installation process.

Installing DotNetNuke has become a very easy task these days, thanks to the installation wizard.  That is one of the best features in the project, as the biggest problem with most web applications is getting the installation completed.  There is one problem with it though.

One of the steps in the installation shows you the status of the database scripts as they are getting executed on the database.  Typically, you would see a completed database script listing as shown in the following image.

Run Database Installation Scripts - Success

However, everyone once in a while, you'll see a listing more like the next image, where an error is just repeated over and over until you stop the website.  The error is "undefined...Success".

Run Database Installation Scripts - Success

I do not know exactly where this happens, but I have narrowed down the fix to this problem.  Well, it is more of a work-around.  Basically, the permissions for the entire website have not yet propogated to all of the child folders and files in your website directory.  The initial file permissions check doesn't validate all files and folders, just the first level.  Getting around this and having a clean and successful DNN installation is quite easy though.

  1. Delete all of the files in the website directory. 
  2. Unzip the installation files back into the website directory. 
  3. Right click on the root folder of your website, and choose the Properties option in the context menu. 
  4. When the properties dialogue opens, choose the Security tab.
  5. Click the Advanced button.
  6. Check the check box to "replace permissions on child objects".

Advanced Security Settings

You will likely need to delete your database instance, and create a new one as well.  I always delete the database as a rule.  But if you want to be sure, check to see if any tables or stored procedures were created.

Technorati Tags: , , , ,

Copyright ©2008 Will Strohl

Tags:

4 comment(s) so far...

Hi Will,

This problem also happens (for me, anyway) when I fail to remember to set appropriate permissions on the database, and skip the verification step. Since I have the world's strangest dev database setup, I assumed it was just me and didn't log it.

Do you have a Gemini work item open? If so, I'll note this there.

By Brandon Haynes on   6/15/2009

I haven't been able to completely track this down yet, but I am able to correctly go through database and file verification. So, a child folder somewhere doesn't have this problem.

I have not yet entered this into Gemini. Usually, when I have this little bit of information and it is not always able to be duplicated, it gets closed. But since you have verified my findings, I feel a little better about doing this now.

By Will on   12/27/2008

I have placed this bug in the DotNetNuke bug tracker:
http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=9034&PROJID=23

By Will on   12/27/2008

These all are just because of database collation guys. try Latin1_General_CI_AS as db collation for dnn database..all your headache will be gone..these problems are source just because of bad dnn documentation..cheers

By inanc on   6/15/2009

Your name:
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Comment:
Security Code
Enter the code shown above in the box below
Add Comment   Cancel 
Add to Technorati Favorites
Tweet about my blog
© Copyright 2004-2009 by Will Strohl. All rights reserved.