In reference to the error "the server principal "xxx" is not able to access the database "xxx_xxx" under the current security context", a Google search brought up many instances of that issue with the common fix being like the following: http://www.hansrasmussen.com/2010/03/...

I don't, however, think that the above issue is causing DotNetNuke to fail in connecting to the database. Since the database was migrated (backup and restore), it is quite possible that you are encountering the a SQL Server user login to database user login mapping problem often referred to as an orphaned database user. Following the database restore, did you or the hosting provider create a new SQL server login using the same username as that used prior to the migration? If so, the new login (even though it has the same username) is not the same internally as the old login. Here's a MSDN link that explains the orphaned user issue and how to resolve it: http://msdn.microsoft.com/en-us/libra...

Because of the potential for this issue to occur during a database migration, I always create a new SQL server login and matching database user login different from that previously used then grant the new database login db_owner permission on the database. Don't forget to make the change in database username and if necessary password in both connection strings in web.config.

---

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

Another thought... Is there a specific reason why DNN can't just let you know the connection string isn't working? I can't believe DNN relies on a failed connection to determine if it needs to invoke the installer.