You are correct in that SQL_VARIANT will store most datatypes, but you cannot take a SUM of the values without converting them. I put together a quick script:

CREATE TABLE TESTVARIANT (INC INT IDENTITY (1, 1) PRIMARY KEY, ITEM SQL_VARIANT)

INSERT INTO TESTVARIANT (ITEM) VALUES ('3E2')

INSERT INTO TESTVARIANT (ITEM) VALUES (3E2)

INSERT INTO TESTVARIANT (ITEM) VALUES (15)

INSERT INTO TESTVARIANT (ITEM) VALUES ('15')

INSERT INTO TESTVARIANT (ITEM) VALUES (3.14)

INSERT INTO TESTVARIANT (ITEM) VALUES ('3.14')

SELECT * FROM TESTVARIANT

SELECT SUM(ITEM) FROM TESTVARIANT WHERE INC IN (3, 5)

SELECT SUM(CONVERT(MONEY, ITEM)) FROM TESTVARIANT WHERE INC IN (3, 5)

SELECT SUM(CONVERT(MONEY, ITEM)) FROM TESTVARIANT WHERE INC IN (3, 4, 5)

SELECT SUM(CONVERT(MONEY, ITEM)) FROM TESTVARIANT WHERE INC IN (1, 3, 5)

DROP TABLE TESTVARIANT

The first sum statement returns:

Msg 8117, Level 16, State 1, Line 1

Operand data type sql_variant is invalid for sum operator.

The second returns 18.14 (correct)

The third returns 33.14 (correct)

The fourth returns:

Msg 235, Level 16, State 0, Line 1

Cannot convert a char value to money. The char value has incorrect syntax.

I included the fourth statement to show that when you insert 3E2 to the table it is stored as 300, but when you insert '3E2' it is stored as a string ... and then won't convert to a money type. This doesn't apply when you insert '15' - not sure why the difference. The type information is stored in the record according to BOL (http://msdn2.microsoft.com/en-us/library/ms173829.aspx)

To sum up, you can use SUM but only if you explicitly convert to an appropriate type - I assumed from your previous post that you didn't want to do this. Also, SQL_VARIANT is stored with a max length of ~8k, so you can add an index but it will break if you store large values in it. And it looks like full text won't work either. From a storage perspective it seems that SQL_VARIANT is fine, but from a reporting perspective it won't be ideal if you ever want to query on it.

Matt.