can someone please tell me if my dnn db settings are correct (as I can't load our website).
Error msg: Site is unavailable.


SQL2005 settings:
I will call our database: dbTest
User trying to connect to dbTest - I will call 'nigel'.

Secuity >> Logins >> nigel >> Properties:
General: login name = nigel
Default database = dbTest (not sure if this matters)
Server Roles = public is checked (although I have tried checkng everything)
User Mapping = dbTest is checked.     user for this = nigel.     default schema = nigel
Database Role Membership = db_owner and public are checked.
Status = Grant & enabled are checked.

dbTest >> Security >> users >> nigel >> Properties:
user name = nigel
default schema = nigel (not sure f this matters?)
Owned schemas: db_owner & nigel are checked
database role membership: db_owner is checked (uner role members)

Securable: got lots of aspnet stuff listed under Name (e.g. aspnet_AnyDataInTables, aspnet_checkSchemaVersion, aspnet_MembershipChangePassword etc - Type = Stored procedure,
Explicit permissions for all these - all have execute checked under the grant column)

Notes;
* We used to have 3 dnn sites - all use the same connection (nigel as the dbo and nigel as the user and same pwd etc) and all used to work ok .

* We recently made some changes - just moved the mdf and log files and back up files to a new location.

*After the above folder change - we had to create new user accounts with a new login in order to get all sites working again.

* I could just use these new security login names to access our site, but I would like to get it up and running as before in order to test something out.... becasue ever since this recent change (not sure if it's related or not, but our DNN upgrades are all failing - due to a permission issue - as shown below.

* Even when I create a new user and set this new user as the db_owner - our upgrades still give the error messages below.

------------------------------------------------
permission issue errors:
System.Data.SqlClient.SqlException: Cannot find the object 'grmApproveRepositoryObject', because it does not exist or you do not have permission.
Cannot find the object 'grmChangeRepositoryModuleDefId', because it does not exist or you do not have permission.
Cannot find the object 'Forum_ThreadViewsDelete', because it does not exist or you do not have permission.
Cannot find the object 'grmDeleteRepositoryAttributeValues', because it does not exist or you do not have permission.
Cannot find the object 'Forum_ThreadViewsIncrement', because it does not exist or you do not have permission.

(upgrading from 5.1 to 5.4 on live server and also from 6.1 to 6.2 on a different development server)

------------------------------------------------

yes, under
programmability >> stored procedures >> the above items which say 'may not exist or don't have permission' for do exist in this list.

e.g
'grmApproveRepositoryObject'
'grmChangeRepositoryModuleDefId'
'Forum_ThreadViewsDelete

etc.. all appear in this list.

Do I need to Modify these stored procedures or add permission somehow? - There's about 340 which failed.

Notes:
* Our development site which failed went from dnn v5.1 straight to 6.1 - which went ok.

* Or Live site went from 5.1 to 5.4 (the correct upgrade path), yet got the above permission errors (although I did at first try going from 5.1. to 6.2).

* Going from 6.1. to 6.2 on development site now gives the permission errors.
thanks.

correction:
On our development server, I thought the problem was down to the database schema not being set to  'dbo'
- as soon as i changed default schema to 'dbo' the site was finally functional after the upgrade, (even though it still gave the errors).

Initially, the default schema on the login (under security) was set to a different schema and resulted in all the dnn modules being corrupt.
- It was thought that the errors remained (on the development site) due to the number of failed upgrade attempts - and that some of the procedures could exist with slightly corrupted names and that I could have both a correctly named and functioning procedure and a misnamed duplicate.

under programmability >> stored procedures >>
I have lots of procedures which start with both 'dbo. xxxx.' and 'another_schema_name.xxxx'