May 13, 2013 at 12:00 pm
I looked at it and could not really understand, however I thought I wanted to read the discussion as to get some incite. I guesses right by process of elimination or could be I am fooling myself and just guessed right.
After reading the discussion I still do not understand. That is how it works sometimes.
🙂
Not all gray hairs are Dinosaurs!
May 16, 2013 at 3:28 am
Danny Ocean (5/10/2013)
Good question, but Explanation is not completed or require more details.I think hugo can help us.
thanks... nice question...
Manik
You cannot get to the top by sitting on your bottom.
May 17, 2013 at 4:46 am
Well, with something like this there are six possibilities only:
1. You know it because you had to find out before and remember the results
2. You run some code to discover the answer
3. You guess and get it right
4. You guess and get it wrong
5. You find some documentation that none of the rest of us have found
6. You know the internal details of select into from having worked on the insides of SQL Server
With a better memory I might fit possibility 1, but (a) I forgot and (b) anyway what applied in SQL 2000 might not apply today, even if I could remember it. I'm lazy and lucky, so I fit possibility 3.
I hope some nice person who fits possibility 5 will post a comment soon. But I suspect no such person exists.
Tom
May 17, 2013 at 8:19 pm
I'm a 3 on Tom's List.
Answer 1 was too obvious otherwise why ask the question.
Answer 1 should be the correct answer but once again SQL Server manages to conjure up an unpredictable answer.
David
May 22, 2013 at 1:43 am
.
May 22, 2013 at 5:01 am
Is there a valid reason for creating the temp table this way instead of explicitly defining the columns? Excuse me if I'm asking a silly question but a lot of this is new to me.
May 22, 2013 at 9:40 am
marlon.seton (5/22/2013)
Is there a valid reason for creating the temp table this way instead of explicitly defining the columns? Excuse me if I'm asking a silly question but a lot of this is new to me.
It's not a silly question at all.
I guess that depends on what you think is valid. Obviously, you write less code to do it with "select into2 that with a separate table definition followed by insert...select, and if you are looking to throw something together in a minute or two that may be important. Obviously though in a case where you have to stop and think about what column types will result and it's going to take a long time to find any documentation that will tell you the types you aren't going to save time by doing it. Apart from that small time saving, there's also the consideration that it makes the code length smaller (especially if there are a lot of columns) and that may be useful for maintenance (it is often easier to maintain something that fits on a page than something that does the same thing but spreads over two pages), and that may be a valid reason to do it. If the table being created is a permanent table it may be preferable to have a create table statement somewhere so that the schema is clearly documented. Most often, there isn't any reason to choose this over declaring the table, or indeed any reason to choose to do it the other way.
Mostly I tend to avoid using this feature, but that's only mostly, nowhere near always, and probably is influenced as much by what I've needed as by how useful the two methods of making a table are.
Tom
May 23, 2013 at 1:38 am
Merci.
May 24, 2013 at 1:03 am
I think the question here simple. Varchar(3) was never tricky. The only eye raising thing was for NULL value. As the SQL server treats default NULL as int, it should be as straight as bamboo(unless we know it). 🙂
Fortunately I knew it and got this correct. But was really a good quesiton.
June 24, 2013 at 9:12 am
The only place in Books Online I can think of that mentions that the type of a literal NULL is integer, is in the ISNULL topic.
The following text was added to the Return Types section in the 2008 R2 version of the documentation:
If a literal NULL is provided as check_expression, returns the datatype of the replacement_value. If a literal NULL is provided as check_expression and no replacement_value is provided, returns an int.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
July 2, 2013 at 8:26 am
Hey what we call these kinds of query ???
September 17, 2013 at 8:40 am
Oracle e.g. throws an error like "ORA-01773: may not specify column datatypes in this CREATE TABLE" in the corresponding "CREATE TABLE ... SELECT NULL...". So this will not help us either 🙁
________________________________________________________
If you set out to do something, something else must be done first.
Viewing 12 posts - 31 through 41 (of 41 total)
You must be logged in to reply to this topic. Login to reply