Dear Group,

I'll admit right up-front: I was not careful upgrading from v.4.3x to 4.8.  I did not backup my entire web site nor my SQL Server database before attempting an upgrade as so many of you have recommended and as all the books and docs say.  Mea culpa.  Mea maxima culpa.

I'm not particularly distressed about it though.  This upgrade process has become a lesson in rolling up my sleeves and digging in.  I merely am curious about some of the issues with installing.

Anyway, to the meat of the issue. My DNN installation is on one of the popular web hosts, CrystalTech.  I've had v. 4.3x installed for over a year without really doing much with it.  However, now I'm working on an ASP.NET application for a client. The nature of the application is such that DotNetNuke is tailor-made to wrap around it into a neat, professional package.

I persuaded my client to rent service from CrystalTech, too, and he did.  I took advantage of CrystalTech's offer of copying all the DNN files to this new site and I installed v. 4.5x without a hitch.  It isn't his site that's the problem.  I thought that I'd stay on the cutting edge of technology and update my own DNN site to v. 4.8 and work out the bugs before upgrading my client's site.

I began with the Upgrade installation of 4.8 without backing up my site.  Again, I will say that I accept all responsibility for my laissez-faire attitude.  When that didn't go all the way, I read up some more in the books I have and in messages on this forum and discovered that using the Install version is the way to go.  Not really being aware of all that was going on in the background I blithely went ahead with copying all the Install version files to my web site and banging away again.  That didn't work either.  So I decided that drastic measures were necessary.

I fired up SQL Server Management Studio (I have SQL Server 2005 on my home system; the web host account is set up with SS 2000), and looked at the tables, views, stored procedures, etc.  I then made a backup of my database.  Too late you say?  Perhaps.

Then I renamed all of the DNN tables on the web host, and deleted all of the DNN stored procedures, views, functions, and even roles.  I thought that I was being quite clever.  I would fool the Install version into thinking that it was making a brand new DNN installation.  I ensured that scenario (I thought) by deleting all the DNN folders and files on the web site and re-uploading the Install version's files.

To make a long story short, I tried the Install Wizard so that I could add the Object Qualifier, though I have since learned that I could simply change a parameter in the web.config file.  I didn't get very far. According to the logs, either tables are missing or constraints already exist.  Also, what I thought would be a from-scratch install looked to be an upgrade installation from 4.3x after all.  At least that's the way the logs looked.  There was a 4.4 installation log, but nothing earlier.

Digging a little deeper into the DotNetNuke.Schema.log, I note a puzzling thing.  The installation routine tries the following:

ALTER TABLE dbo.[dnn_RoleGroups] ADD CONSTRAINT [PK_dnn_RoleGroups] PRIMARY KEY NONCLUSTERED  ([RoleGroupID])

...but that raises this error:

System.Data.SqlClient.SqlException: There is already an object named 'PK_dnn_RoleGroups' in the database.

That's because the database does, indeed, contain a PK_dnn_RoleGroups constraint...but it's for the renamed RoleGroups table!

So, I've outsmarted myself.  I thought that by renaming all the old DNN tables I could get away with a clean install.  Not so.  What would you suggest?  The database I'm using for DNN has a lot of other stuff in it, so I'm not real thrilled about the idea of chucking it and creating a new one.  Besides, my web host would certainly charge me for the privilege.

One other thing: since the (supposedly) fresh install was really an upgrade install even though all the old tables had been renamed, where, exactly, is DNN getting the information about where to start its upgrade routine?  Is it a .config file I've missed? Does DNN make an entry in a system table somewhere?

Thanks very much for your help.

Sincerely,

Steve Erbach
Neenah, WI

Sebastian,

Yes, mother!  (Just kidding)

Regarding the (re-)naming of hidden objects, yes, that's what I found out; namely, that PK's and such don't get renamed right along with the tables I've renamed.  However, a thought occurs to me: instead of using "dnn_" as the object qualifier, I could simply use a different one.  I think I'll try that.

As far as using a new database, technically speaking, that is an option.  However, since I rent SQL Server capacity from my web host, that means deleting my existing database with tons of other stuff in it besides DNN, and then paying for the creation of a new database.  The cost is not high, but my whole reason for posting my question was to find an option other than that drastic one.

I've done numerous local installations but I don't see how that helps me with the installation on the web host.  Installation of the ASPX files and the configuration of the web.config isn't the issue -- other than the object qualifier -- it's the SQL Server database itself.

Again, I'm looking to "fool" DNN into thinking that I'm creating a new instance of DNN and not upgrading an existing one.  I think the object qualifier change is the answer.  Thank you.  I'll report back and mark this issue as resolved if that works.

Steve Erbach
Neenah, WI

Steve, I would go back to the backup before the rename (if I understand your story, you made one after upgrade but just before renaming). Then, what exactly went wrong in the upgrade?