SQL Server's cross-version collation support

by Michael S. Kaplan, published on 2006/05/25 19:11 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/05/25/607504.aspx

I had the day off today, though I did end up going to a meeting or two with some SQL Server folks (they set the meeting up before I was told we were getting the day, and I didn't want to make them suffer for the tardy notice!).

In between meetings, I was talking to someone who pointed out that although they enjoyed reading my blog that they thought I had the wrong take in posts like this one and this one when I talk about the differences between SQL Server collations.

He knew that the docs say "[in] Reserved. Must be NULL." and that perhaps it would never be hooked up, even in a future version like happened in the MessageBoxIndirect case. But clearly there appears to be some future thought toward thesupport of multiple versions, even if it never happens.

So, in this context, he asked me how the core scenarios of such a future version of the collation functions would be any different than the scenarios that SQL Server has had available to it since SQL Server 2000. Wasn't I perhaps being a bit too hasty in talking about the cross-version support's problems when I should actually be thinking about this first foray into multiple version support so that I could learn from it?

I thought about it and in the end I must admit that he has a point here -- not taking the time to understand all of the problems and benefits and opportunities and even bugs that come out of the SQL Server implementation would actually force a future Windows implementation to work through the exact same problems/benefits/opportunities/bugs all over again!

A pioneer deserves the credit for its place in history, so a quick nod to SQLS, and I'll do some thinking about these things.

Some of my thinking I will do aloud here, within the context of all of things that are both possible and impossible within SQL Server (2000 and 2005). Perhaps we can all learn something. :-)

I have always beed puzled by APIs having parameters "Reserved. Must be NULL"
It feels like they are designed to be extended, but is not really possible to do it, because of backward compatibility. So why "reserve" something that will never be used?

Actually, it certainly can be used in the future; the only limitation is that in the future NULL must still be valid.

Future functionality (which is not supported on the old platforms) would be non-NULL, and would be supported on the new platforms.

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.