More m$ rubbish, SQL 2008 this time

Though, this one seems to go as far back as Sybase.

I tried to make a field binary, i.e. change its type from char(10) to binary(10). The contents should stay the same - I am only changing the behavior of the field in some cases, like when coming over the wire to an ODBC client near your Windowses with a non-Western codepage. IOW, the field may, in the future, contain nonprintables.

So I try to run this command:

alter table mytable alter column myt_code binary(10)

The first fail is the message "SQL Server Database Error: The object 'Dflt_EmptyString' is dependent on column 'myt_code'."... Huh? Something will happen to the database-wide default if I change one column? And that new column is just another string, so the default would apply to the new version of the column just as well. But no, it's not only the message which is wrong way around (the column is dependent on the default, not vice versa), it's the ass backward idea that it's the programmer's duty to remove such dependencies manually. The idea of trying to unbind - try if it still works - bind again... simply didn't occur to anyone in M$. Did anyone refuse to buy SQL server because of this? So it won't be changed, it's not a feature.

OK, you have it. I'll unbind. Done. Try again. Bang!

Implicit conversion from data type char to binary is not allowed. Use the CONVERT function to run this query.

Why? Why is any conversion necessary. It's one type of string to another type of string, and the first type is actually a subset of the latter. Such a rule makes sense when you try to change type from any numeric to any string type, even though there are other databases where the conversion happens on the fly (you get string representation of the numbers, or a numeric value of any number string contained in the string).

Know what? I'm not doing this. TSQL doesn't support it, period.