Having just ground through my first update of a live DNN site from a staging site, I can say it would have been impossible without the RedGate tools.  Even then it was non-trivial and extremely frustrating.

My problem was compounded by the fact that our site designers didn't realize that creating a new portal and adding pages (and I came on the scene after they had already done this) would compete with pages being added in the dev site (Tabs are shared across portals so there is competition for the next TabId).  To solve this, I had to copy down the production to staging, delete the new portal in staging, create the new portal in dev, and then copy data across to staging.  And then had to synch the staging with production  Since I'm not absolutely sure which tables relate explicitly to users (Users, UserRoles, aspnet_...,), production (EventLog, Scheduling, Search, etc.), and site content (Tabs, TabModules, etc.),  and the same question for website files (production vs common site), it was a trial and error process to see which tables and files should be copied.   Put another way, I can't simply copy all files/tables/rows into the dev site, nor can I simply copy all files/tables/rows from dev into production.  Consequently there was a middle site, staging, where I staged all the changes I was going to make and even then I still made mistakes.  And my problem wasn't made any easier by the restricted ability to do things on our hosting site at Verio (for instance, can't simpy upload a SQL backup and restore from it).

I agree with Scott Willhite that a robust model is needed here as we have an application we host with DNN and use it to control user access to pages (which are part of the application).  We simply can't make those changes to production as it would end up in an unstable mess.  That's why everything is done in dev first and then signed off before being pushed into production.

Anybody got a bottle of Scotch they'd like to share with me?

Jerome Dayton

Big Kahuna Technology