Christian Hayter's questions

I have a database for which I want to restrict access to 3 named individuals. I thought I could do the following:

1. Create a local Windows group on the database server and add the named individuals to it.
2. Create a Windows login in SQL Server mapped to the local Windows group.
3. Map the login to the "dbo" schema in the database, so that the users can access all objects without having to qualify them with the schema name.

When I try to do step 3, I get the following error:

Msg 15353, Level 16, State 1, Line 1
An entity of type database cannot be owned by a role, a group, an approle, or by principals mapped to certificates or asymmetric keys.

I have tried to do this via the IDE, the sp_changedbowner sproc, and the ALTER AUTHORIZATION command, and I get the same error each time.

After searching MSDN and Google, I find that this restriction is by design. Great, that's useful. Can anyone tell me:

1. Why this restriction exists? It seems very arbitrary.
2. More importantly, can I accomplish my requirement some other way?

Other info that might be pertinent:

• The server is fully up to date with service packs and hotfixes.
• All objects in the database are owned by the "dbo" schema, and it's not feasible to change that.
• The database is running in compatibility level 80, and it's not feasible to change that to 90 yet.
• I am free to make any other changes (within reason, depending on what they are).

DISCLAIMER: I know that this question has been asked a hundred times before, but I just wanted to check that there wasn't an easier solution I might have missed before I went ahead and wrote/sourced lots of code to do it.

Our software uses a database that was originally designed for SQL Server 7, and as such, all the scripts that create it do not specify any explicit collation for any character columns. Instead, when a database is created/restored to SQL Server 2000 or above, every column inherits the database collation (which happens to be SQL_Latin1_General_CP1_CI_AS since that was the SQL Server 7 default).

Theoretically, this would not matter too much, since if our database is created from scratch on a customer's server, it inherits the customer's server collation (which is normally the modern installation default, Latin1_General_CP1_CI_AS) and everything just works. However, this scenario breaks down when they send us a database backup, or we send them a database backup, and either we or they get the dreaded collation mismatch error whenever the code tries to access temp tables etc.

We have tried educating customers to install or rebuild their SQL Server instances to use our preferred collation, but of course that doesn't always happen and it's not always possible.

Solutions that involve creating a new database and copying the data are not really practical for us, we need a "magic wand" that we can wave at a live database to correct all columns in-place without disturbing the data. I am thinking about writing a utility to do this, but since it will be quite a big job, does anyone have any simpler suggestions?