Comments on: Check the settings when installing SQL Server

By: Rob Farley

Rob Farley — Thu, 13 Aug 2015 07:23:57 +0000

Yes, Trevor, and I really wish they had’ve developed the "contained database" concept more.

By: Trevor

Trevor — Thu, 13 Aug 2015 07:01:49 +0000

I’m sure you’re already aware, but it’s worth noting that this behaviour changes when you use a DB that is set for partial containment. Once set it defaults to creating temporary tables in the database default collation.
So while the primary reason for containment is security, and it’s a sledgehammer approach to contain a DB for this reason the option is there.

By: Rob Farley

Rob Farley — Mon, 27 Jul 2015 04:32:49 +0000

Yes, I agree with that aspect too. But that connect item is not just about tempdb, but anywhere that collation errors occur. System tables use the default instance collation, and we should take care to avoid errors when dealing with them too.

By: Marcel

Marcel — Mon, 27 Jul 2015 03:38:55 +0000

"The real problem is that temp tables have tempdb collation. That is never useful. They should have the collation of the database that creates the table."
Agree with Mark here. The default behaviour should work for the 99% of cases. If I ship an enterprise produce internationally, the first problem encountered is restoring our base db onto a server with a different collation. When the customer supplies the db server, this is always a problem (in our case this is 100% of the time). The default collation for them is directly dependent on their machine locale. They have other systems on their db servers. Our application operation is directly dependent on the collation we have built our app upon and regression tested against. Having to specify database_default everywhere is poor design.

By: Rob Farley

Rob Farley — Wed, 15 Jul 2015 03:28:45 +0000

All code that created columns without an explicit collation is dependent on database settings already. My suggestion in the Connect item was to have a way of avoiding the error, and a few different options were provided. And the real fix is to have people always specify the collation explicitly, so that even the database collation isn’t relevant, let alone the tempdb collation.

By: mark

mark — Tue, 14 Jul 2015 17:28:35 +0000

It also will increase the amount of code that runs but has wrong results and the amount of code that depends and requires a certain database setting. In fact what if you want to run different pieces of code with different settings? Often a database hosts multiple apps or clients.
One nasty aspect I did not mention before. The ticket breaks the fact that (a=b) is identical to (b=a).
Again, the real fix is to not make temp tables depend on internals of tempdb. We have a clean fix, there is no need to add bad language design.

By: Rob Farley

Rob Farley — Tue, 14 Jul 2015 17:03:06 +0000

You already can’t execute code and just assume it’s going to work. A different collation is a common cause of that. The Connect item is trying to increase the amount of code that will simply work, although of course indexing strategies need to consider the collation settings carefully.

By: mark

mark — Tue, 14 Jul 2015 16:26:36 +0000

I did not realize it was your item. I should have elaborated: Settings that influence the valid T-SQL that you can write or its behavior are evil because it’s a trap waiting to hit. You can no longer use code on the web or publish code to the web because you might accidentally depend on some setting. That’s why the ANSI NULL setting is deprecated although it clearly makes the language better. Bad language design.
It’s action from a distance. It breaks stuff without you being able to audit for it.
This is like the VB language options which I’m sure the team regrets.
Also, this is a little like ON ERROR RESUME NEXT.

By: Rob Farley

Rob Farley — Tue, 14 Jul 2015 15:59:28 +0000

I’m sorry you don’t like the Connect item, Mark. The point of the Connect item is to have an option that means that a collation error can resolve with a warning.
There is no issue specifying a collation when creating a temporary table, and DATABASE_DEFAULT is better than nothing.

By: mark

mark — Tue, 14 Jul 2015 15:03:19 +0000

That connect proposal is really horrible. What bad language design.
The real problem is that temp tables have tempdb collation. That is never useful. They should have the collation of the database that creates the table. This behavior is so bad and broken that it borders on a bug.
It certainly is *not* best practice to specify COLLATE DATABASE_DEFAULT on all temp tables. It clutters the code. This should be done if necessary. The better solution is to ensure that all databases have the same sane collation. If that is not possible you might need COLLATE DATABASE_DEFAULT.