SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Variant order 1


Variant order 1

Author
Message
Tom Hamilton
Tom Hamilton
Hall of Fame
Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)

Group: General Forum Members
Points: 3476 Visits: 792
w00t
In the interest of being exact, the answers given transpose the 3rd field so there was not exactly correct answer given...

Here is the result:

v1 > v2 v1 > v3 v3 = v2 v4 > v1

Tom in Sacramento
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
David Data
David Data
SSC Eights!
SSC Eights! (863 reputation)SSC Eights! (863 reputation)SSC Eights! (863 reputation)SSC Eights! (863 reputation)SSC Eights! (863 reputation)SSC Eights! (863 reputation)SSC Eights! (863 reputation)SSC Eights! (863 reputation)

Group: General Forum Members
Points: 863 Visits: 828
I see that even if you set
@v1 sql_variant = cast ('15.00' as float(53)),
@v2 sql_variant = cast ('16.00' as decimal(18,4)),

which makes
v1 v2
15 16.0000

SQL Server still says v1 > v2.

This behaviour is very counter-intuitive - to say nothing of being arithmetically incorrect!

It would be better if it produced the result one would expect - or if it won't, if it refused to do such comparisons. I can imagine many data errors being caused by people not noticing this behaviour and believing the wrong results they get.
Britt Cluff
Britt Cluff
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2375 Visits: 253
Good question, but a lot of reading. Thanks for submitting.

http://brittcluff.blogspot.com/
Carla Wilson-484785
Carla Wilson-484785
SSCrazy
SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)

Group: General Forum Members
Points: 2286 Visits: 1951
Toreador (11/30/2011)
KWymore (11/30/2011)
I am curious how many out there are utilizing sql_variant and under which circumstances?


I've used it for generic audit tables, where we store something like table name, column name, old value, new value - the old/new values are sql_variant as they could be any data type.
Of course you'd never do any comparisons between different data types in these circumstances.


Toreador, thanks! I, too, was wondering where one would use sql_variant - now it seems obvious.

That said, I appreciate David Data's comment:
David Data (12/1/2011)
I see that even if you set
@v1 sql_variant = cast ('15.00' as float(53)),
@v2 sql_variant = cast ('16.00' as decimal(18,4)),

which makes
v1 v2
15 16.0000

SQL Server still says v1 > v2.

This behaviour is very counter-intuitive - to say nothing of being arithmetically incorrect!

It would be better if it produced the result one would expect - or if it won't, if it refused to do such comparisons. I can imagine many data errors being caused by people not noticing this behaviour and believing the wrong results they get.


I really don't understand why someone would want to do a comparison that is based on the data type. I can only guess that they chose to set it up this way to avoid errors that might occur in implicit conversions. The lesson I learn from this is to not do comparisons on sql_variant.
Hugo Kornelis
Hugo Kornelis
SSCoach
SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)

Group: General Forum Members
Points: 18809 Visits: 12426
Carla Wilson-484785 (12/1/2011)
I really don't understand why someone would want to do a comparison that is based on the data type.

Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.

They chose the former, and then had to come up with a way to compare the numeric value 15, the string value N'fünfzehn', the date December 1st, 2011, and the bit value 1. Which one is more than the others? And why? They had to make a choice - but whatever their choice was, it was bound to be perceived as wrong for some cases.
That being said, I do share your amazement at the choice to put exact and inexact numerics in two different groups. It appears this choice was born out of technical rather than functional considerations.

The lesson I learn from this is to not do comparisons on sql_variant.

Amen to that!


Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Tom Thomson
Tom Thomson
One Orange Chip
One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)One Orange Chip (25K reputation)

Group: General Forum Members
Points: 25977 Visits: 12494
Hugo Kornelis (12/1/2011)
Carla Wilson-484785 (12/1/2011)
I really don't understand why someone would want to do a comparison that is based on the data type.

Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.

Given that they wanted people to be able to construct indexes on sql_variant columns, they didn't have a choice - they had to provide a total order on SQL_VARIANTs. Not allowing it at all was not an option.
They chose the former, and then had to come up with a way to compare the numeric value 15, the string value N'fünfzehn', the date December 1st, 2011, and the bit value 1. Which one is more than the others? And why? They had to make a choice - but whatever their choice was, it was bound to be perceived as wrong for some cases.
That being said, I do share your amazement at the choice to put exact and inexact numerics in two different groups. It appears this choice was born out of technical rather than functional considerations.

I can't really think of any purely "technical" considerations that would suggest making them two separate type families; perhaps an awareness that conversion from exact to inexact numerics (which is the conversion that would have to be done to allow comparison if they were in the same group) can cause bizarre rounding effects (as can the conversion in the opposite direction, of course) could be considered a technical consideration but I would consider avoiding such effects as a fundamental requirement of indexing (and in particular of having UNIQUE constraints supported by indexes) so I see it as rather an essential requirement of the SQL data model rather than something merely "technical".
The lesson I learn from this is to not do comparisons on sql_variant.

Amen to that!
[/quote]
Yes, Amen to that from me too - as far as I am concerned, the only real uses for SQL_VARIANT ordering are (i) to support indexes and unique constraints and (ii) to provide material for technical trivia questions like this one.

Tom

Carla Wilson-484785
Carla Wilson-484785
SSCrazy
SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)

Group: General Forum Members
Points: 2286 Visits: 1951
L' Eomot Inversé (12/1/2011)
Hugo Kornelis (12/1/2011)
Carla Wilson-484785 (12/1/2011)
I really don't understand why someone would want to do a comparison that is based on the data type.

Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.

Given that they wanted people to be able to construct indexes on sql_variant columns, they didn't have a choice - they had to provide a total order on SQL_VARIANTs. Not allowing it at all was not an option.

Thanks, that makes sense.

L' Eomot Inversé (12/1/2011)
Hugo Kornelis (12/1/2011)
The lesson I learn from this is to not do comparisons on sql_variant.

Amen to that!

Yes, Amen to that from me too - as far as I am concerned, the only real uses for SQL_VARIANT ordering are (i) to support indexes and unique constraints and (ii) to provide material for technical trivia questions like this one.

Fair enough! (thanks for the explanations!) :-P
Koen Verbeeck
Koen Verbeeck
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: General Forum Members
Points: 62458 Visits: 13298
Great question, thanks!


How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?
My blog at SQLKover.

MCSE Business Intelligence - Microsoft Data Platform MVP
BudaCli
BudaCli
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1558 Visits: 598
nice one

What you don't know won't hurt you but what you know will make you plan to know better
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search