Regarding #1 - When you over-wrote Database.mdf on the remote server and assuming that the remote server was using Database.mdf, you essentially replaced the content (except for image and other document files) on the remote server with that of the localhost. Because it is unlikely that both localhost and remote servers were of the same DotNetNuke version with the identical type and version of modules, skins, and other extensions installed, this will likely render the site un-repairable. If you have not already done so, try to restore the remote Database.mdf file from a recent backup. The redirection to the install directory when you hit the remote site is an indication that it can no longer connect to its database or that the database is of a different version than that of the DotNetNuke assembly. A look at the remote site's web.config file's database connection strings will indicate if that site was making use of Database.mdf or connecting to a different MS SQL Server database. If the latter, the site may be recoverable as the issue may have been caused by accidental changes to files other than the database.

Regarding #2 - With the exception of image and other document files, skin files, etc.  that may have been uploaded to the site, all of the site's content is stored in the database. With the exception of default.aspx (which should NOT be modified), all of the "pages" that you create and modify are not physical pages but are created on the fly from the contents of the database. Therefore it is not possible to upload updated pages, such as the "Home" page to the remote site. In most cases it is best to make changes only to the remote site and not to the local site with the expectation that local changes can then be uploaded or published to the remote site.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

regarding 3, please read here: http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/1202/DNN-SQLExpress-SQL-Server-Management-Studio.aspx I always prefer using attached databases instead.

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN