Hi,

I've successfully installed DNN.  Here is my setup: VS2005 Professional with source code and SQL 2005 Enterprise. The production server has IIS6, NET framework 2 and AJAX.  SQL server is a remote instance.

Here is my problem.  On my desktop machine, I have IIS 5 and DNN installed as a solution in VS2005.  The DNN instance on my desktop talks to a dev database on the production server.  The production DNN website talks to a production database different than that of the dev database. 

Typically, a module or skin will be developed and tested on the desktop environment, then deployed to the production web server.  This involves registering these modules to the dev database. However, at the time of testing, they are not registered to the production database.  Once pass testing, they are deployed to the production server, then the developer will need to go through the whole process of registering them with the production server. 

The other side of the problem would be the editors of the production web site.  Their change will not be reflected in the dev database, therefore, the developers won't see these content changes. 

I can't have both groups of users connecting to the same database because that will be risky in that not fully tested modules might become available to users. 

The source of the problem is a disconnected state between the dev and production database.

Any suggestions will be greatly appreciated.

Best,

Kevin

Hi Tony,

Thank you very much for your reply. 

Your setup is very good in that it simplies a lot of the problems that might have been caused by the discrepancy between the production and development. Your version control is also a very good practice.

We are still new in our use of DNN.  My concern is, as a content management system, the power of DNN is to give it to the editors/users who can then regularly go in the site and update the content of pages.  When they do it, then the pages content will be written into the database causing disparity between production db and development db.  The pain will be these content will be changing constantly and sync-ing the two dbs will be a lot of overhead.  Furthermore, the editors will work within the framework of the DNN site.  For instance, they won't have access to a not fully tested module.  So developers/coders will have to be separated from the production site and db.  Thus, unless I can sync the dbs with ease, there will always be differences between them.

But I guess there is no easy way out in this regard.  I still very much like your practice and it gives me a lot of good ideas. Instead of syc-ing all the time, I can sync on a regular basis, less frequently, for the developers so they can have a good taste on how the production site looks like. I will look into ways of mirroring the database, if it is not too much stress on the database server.

Thanks again for your advice,

Kevin

 Hey Temp,

When we make content changes, we make all of the content changes in the development site.  The live site is _NEVER_ changed unless we have an "emergency" content update that has to be made (for example, a new version of DotNetNuke comes out).  When we have to do an emergency content update, we make the change on the live site and then we go and make the exact same change on our development site.

The development version of our website is always a future version of our production website.  Our production website is always a "snapshot in time" of our development website.

I hope this clears things up.