|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Today @ 9:57 AM
Points: 464,
Visits: 1,236
|
|
Stewart "Arturius" Campbell (3/13/2013)
Interesting question, thanks Dave Another way to check the detail of the temp table would be to execute tempdb..sp_help #TempQoD
Now this is very very new thing to me... thank you.
(and for the INTO.. table stuff, I thought it is obvious... like when you use the import/export tool and when you trying to import the data from the excel file it marks all the column as varchar except the first one if there are any number like 1 2 3... it marks as int... and if we need the col type to any specific then the tool allows us to modify the value accordingly. As the source data is like a variant, I thought it will be difficult to sql to pick the exact datatype to meet the source and the destiny.... until proven otherwise. This is very interesting, thank you for posting the question, Dave)
ww; Raghu -- There are only 10 types of people in the world, those who understand binary, and those who don't.
Note: (as of now) only.. 1 and 4 applies (i am on my way...)
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Today @ 9:57 AM
Points: 464,
Visits: 1,236
|
|
Carlo Romagnano (3/13/2013)
Good!
+1
ww; Raghu -- There are only 10 types of people in the world, those who understand binary, and those who don't.
Note: (as of now) only.. 1 and 4 applies (i am on my way...)
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Today @ 7:11 AM
Points: 1,130,
Visits: 1,278
|
|
Raghavendra Mudugal (3/13/2013)
Stewart "Arturius" Campbell (3/13/2013)
Interesting question, thanks Dave Another way to check the detail of the temp table would be to execute tempdb..sp_help #TempQoD Now this is very very new thing to me... thank you. (and for the INTO.. table stuff, I thought it is obvious... like when you use the import/export tool and when you trying to import the data from the excel file it marks all the column as varchar except the first one if there are any number like 1 2 3... it marks as int... and if we need the col type to any specific then the tool allows us to modify the value accordingly. As the source data is like a variant, I thought it will be difficult to sql to pick the exact datatype to meet the source and the destiny.... until proven otherwise. This is very interesting, thank you for posting the question, Dave) New thing for me too
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Today @ 7:11 AM
Points: 1,130,
Visits: 1,278
|
|
Stewart "Arturius" Campbell (3/13/2013)
Interesting question, thanks Dave Another way to check the detail of the temp table would be to execute tempdb..sp_help #TempQoD +1
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Sunday, May 05, 2013 11:42 AM
Points: 374,
Visits: 326
|
|
Stewart "Arturius" Campbell (3/13/2013)
Interesting question, thanks Dave Another way to check the detail of the temp table would be to execute tempdb..sp_help #TempQoD
I often use sp_help to get db object info, but never try the query on explanation. That query can be handy since it provides more info about a particular table. Thank Dave!
Derived on the query on the explanation, this query can be used to object info for other db objects such as trigger and stored procedure.
USE tempdb; go SELECT * FROM sys.objects o LEFT JOIN sys.columns AS c ON c.object_id = o.object_id LEFT JOIN sys.types AS t ON t.system_type_id = c.system_type_id WHERE o.object_id = object_id('#TempQoD');
-------------------------------------------------------------------------------------- Hai Ton My DB4BREAKFAST blog: http://db4breakfast.blogspot.com
|
|
|
|
|
Say Hey Kid
      
Group: General Forum Members
Last Login: 2 days ago @ 6:18 AM
Points: 691,
Visits: 1,104
|
|
| Great question. I also got the answer by running: " EXEC tempdb..sp_help '#TempQoD'; "
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 9:42 AM
Points: 1,072,
Visits: 1,026
|
|
I nominate this question for Best Question of the Month! Well-written and has real world implications if not understood.
But, I will point out this is not just true for the creation of temp tables (as the title "Temp Table Data Types" suggests.) This happens when you create regular, permanent tables, too, which I think it the most hazardous reason of all not to use "Select Into" to create a new table.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Today @ 11:59 AM
Points: 1,362,
Visits: 859
|
|
This behaviour isn't exclusive to select into, it has to do with how SQL Server determines data types from values that aren't explicitly typed. For example:
select case when 1 = 0 then 0 else 'test' end The code above will return a conversion error from string to int, because the data type was inferred to be int (of course the definition of which value should be converted has to do with data type precedence).
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Today @ 2:14 PM
Points: 3,250,
Visits: 65,559
|
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Today @ 7:32 AM
Points: 1,059,
Visits: 1,396
|
|
I wasn't sure what the confusion was here. All of the values in the example SELECT...INTO are constants. When you create a constant, the format you express it in tells SQL Server what data type to use. It's that simple.
Then, I read Microsoft's documentation on constants here: http://msdn.microsoft.com/en-us/library/ms179899.aspx . If you value your sanity DO NOT READ MICROSOFT'S DOCUMENTATION ON CONSTANTS. They manage to get it COMPLETELY WRONG. This is the worst Microsoft documentation I have seen to date.
It starts with this: "The format of a constant depends on the data type of the value it represents." That's completely back-to-front. You create the data type and express it in a format first, then SQL Server interprets what it is based on the format you provide. The correct statement is "The data type of a constant is based on the format passed to SQL Server." It then goes on to provide several data type examples, including a lot of "date" constants which are actually all varchar constants.
What this means for this question is that '15 Jan 2013', being formatted as a varchar, is interpreted by SQL Server as a varchar. It will be treated as varchar by SQL Server until you tell SQL Server to treat it as something else, either by an explicit CAST/CONVERT or by assigning it to an expression already typed as something else.
It's that simple.
|
|
|
|