Hello, I really need some help here, am totally stumped on something basic I must be missing or, something in 6.2 which doesn't allow an easy copy of database, site content to make a production site from a dev site.

I get this:

The Auto option has been disabled as the DotNetNuke Application cannot connect to a valid SQL Server database. You can continue to use either of the other two Wizard options and configure the Database settings at the appropriate Wizard step.

This is because when I browse to the site I just copied and set up in IIS 7, for God only knows what reason, the site tries to install itself.

I have done:

1. Copy the content folder and renamed it Production_Non_SSL to just get the site working as http://, etc.
2. Created an SQL 2008 R2 DB (our version is SQL Workgroups).  The db name is Production_Non_SSL
3. Edited the web config above, changing the db name in all connection strings
4. For the static IP I'm using, edited the Portal Alias table accordingly for all portals of the copied site
5. Set up IIS to connect to the content, for the moment, not applying the SSL Cert
6. Browsed to the IP, which went righ to http://209.213.120.92/Install/Install... and NOT to the home page. :)
   1. Note, I can in fact browse to a testpage.html in the directory of the Production_Non_SSL/Website/ path.  So ... the database HAS to be working.  Else, the Portal 0 alias would not be working ... I'm sure that's not a leap in logic but then again, this has me frustrated.
7. By the way, set up the Website folder with IIS Default App Pool having Modify Access and NetworkService having full control.
8. Verified the copied database has the NT Authority Service and Default App Pool in it from the backup I used to restore over the database
   1. Note, I thought of removing/re-adding both users in SQL but since I get the error these are DB Principals and can't be removed, the assumption is they must be valid users.  That is, it used to be that sometimes the users were incorrect since another db backup (from development site) was used to restore over the site.  Since I can't delete the users, my assumption is SQL has them correctly set up and this might be the reason things are not working.

From the above, it seems I've covered the bases.  When I moved the 4.9.0 site over to our new server I did the same process for that DNN Version.  Upgraded it to 6.2.0 easily and got it working perfectly.  Now, it's time to make the production site and I've never had so many headaches.

It has to be something easy was missed.  Well, the machine keys are right, connection strings are right, etc.  Web config, db, permissions, etc. are in order.

Please someone info me what I've missed.  It is something bsic as this isn't rocket science so ... I've sucked it up that it's going to be an obvous answer.

Thanks!

Mike

Sebastian,

 Thanks for getting back.

Here's the connection string.  I've tried this with " . " and as " localhost " as the sql instance.

<add name="SiteSqlServer" connectionString="Data Source= . ;  Initial Catalog=Production_Non_SSL;  Integrated Security = true; Connect Timeout = 0" providerName="System.Data.SqlClient" />

I copied the Catalog name by right clicking the database and using "Rename" to copy it and then paste it into the web.config.  TCIP for sql server and client I think are a non issue since other databases are working with their respective DNN sites.

I'm sure it's a silly oversight or just some minor change in how DNN is set up now vs. how I've learned it since 3.x -- a really easy "Oh ... we do this now ...:" sort of thing.

At any rate, no joy on trying the instance name thing.  Thanks though.  Any other hiccups you've seen as oversights -- as we call them in English "Duh's " ?

 

Thanks,

 

Mike

When you move a database from one sql installation to another (detach and attach), you will end up with an orphaned database owner.
Create a new user in the destination sql server, make the new user db_owner and change account and password in web.config.
I vaguely remember you're better off selecting a different account name for the new db_owner.