Greg Chagnon
3/20/2007 3:14:00 PM
"Razvan Socol" <rsocol@gmail.com> wrote in
news:1174370657.939475.171290@l75g2000hse.googlegroups.com:
> It would be nice if in this case SQL Server would behave as if it
> would execute automatically an ALTER TABLE <tbl> ALTER COLUMN <col>
> <newdatatype> for each table involved, inside a transaction (so it
> would rollback all changes if the data in any table could not be
> converted).
>
> Razvan
>
Right, that's exactly what I am asking.
As things stand, you have to change the definition of all fields in all
tables that use the user-defined type, then change the user-defined
type, then REMEMBER what all fields previously USED that user-defined
type if you want to have them use that user-defined type again.
This last part -- keeping track of just which fields had used that type
-- is maybe the hardest part.
My first thought was that the PURPOSE of user-defined types was so that
you COULD easily change the type and have it applied everywhere. So
obvious!
Wei Lu's comment (which follows this one) suggests that you can do all
this in one transaction. That is true, IF you have some external
mechanism to keep track of which fields use the user-defined type.
Which kind of defeats the purpose of the user-defined type in the first
place!
Wei Lu's first comment, that such a chnage could invalidate data in
tables or indexes, doesn't make much sense to me. How could changing a
data type invalidate data (other than any other change that might
already invalidate data, like changing an Int to a Smallint? This kind
of ALTER statement is already checked for by SQL Server when you use
ALTER.
I generally envision this change to make fields bigger (Int to Bigint),
or to make Char or Varchar fields wider, etc. Still, since you can
already ALTER column definitions, SQL could internally do what I am
asking.
I posted a request at connect.microsoft.com/sql. We'll see if anyone
votes on it. (Many requests there don't get ANY votes.)
David Walker