Wednesday, November 30, 2011

Terminating this procedure. 'dbo' is a forbidden value for the login name parameter in this procedure.

I was trying to move a database from one server to the other. After successfully restoring the database. I ran the orphaned users report and found a couple of users and I fixed them by creating new logins for them.

The user dbo was being reported as an orphaned user and if tried to run the command to fix it I would get the following error.

Server: Msg 15287, Level 16, State 1, Line 1
Terminating this procedure. 'dbo' is a forbidden value for the login name parameter in this procedure.

The fix for this error is to run the following command.

Exec sp_changedbowner 'sa' 



If you are still getting a list of orphaned users then do the following.
1) This will lists the orphaned users:
    EXEC sp_change_users_login 'Report'

2) If you already have a login id and password for this user, fix it by running following command for    each user
    EXEC sp_change_users_login 'Auto_Fix', 'user'

3) If you want to create a new login id and password for this user, fix it by running the following command for each user. Make sure you assign the password and give that to the user.

  EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'

Error: 18456, Severity: 14, State: 11

Error: 18456, Severity: 14, State: 11.
Login failed for user 'domain\loginname'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: <local machine>]

There are several reasons because of which you could get this error but the primary reason is as follows.
Typically, when you are asked to provide access to a SQL Server instance, you would create a new login (windows or SQL) in the SQL Server instance.

But sometimes the person who is responsible for creating an account for you and give you sysadmin role,  will add your windows domain login to the LOCAL ADMINISTRATIVE login group. This is assuming the fact that the local admin login is a sysadmin on SQL Server instance. So I have always wondered why we get this error.

But the easy fix is to explicitly create a new login with Windows Authentication in the SQL Server instance and assign the server role to that ID.


Tuesday, November 15, 2011

Upgrade path for SQL Server Edition and version

Upgrade path SQL Server 2005 Express to SQL Server 2008 Standard

Recently I had the task of upgrading from SQL Server 2005 Express edition to SQL Server 2008 Standard edition. I assume that you would have the same issue if you had to upgrade from SQL Server 2005 Standard to SQL Server 2008 Enterprise Edition.

It seems that you can not upgrade both the version (2000 to 2005 to 2008) and also the edition  ( Express to Standard to Enterprise) in one change. You have to first upgrade either the version or the edition and later you can upgrade the other. Depending on what Version and Edition of SQL Server you are running use the following two links to determine your upgrade path.



If you are reading this email after 2008 then I assume that you might be planning to upgrade to SQL Server 2008. To illustrate an example lets consider that you want to migrate from SQL Server 2005 Express to SQL server 2008 Standard. Then you can follow one of the two following paths.

1) SQL Server 2005 Express to SQL Server 2005 Standard. Later upgrade to SQL Server 2008 Standard.
2) SQL Server 2005 Express to SQL Server 2008 Express. Later upgrade to SQL Server 2008 Standard.

The path that want to take would be determined by what is more important to you. In my case the client wanted an upgrade from Express to Standard edition so I took the first path. That way in the very first segment I would have achieved what the client wanted. There could be several other things to consider before you make the decision. 

One more thing to consider is upgrading from 32 bit to 64 bit.  Microsoft does not support a 32 bit to 64 bit inplace upgrade. Please follow the preferred method to upgrade from 32 bit to 64 bit.