May 9, 2013 at 11:14 pm
tough one for weeks end
Hope this helps...
Ford Fairlane
Rock and Roll Detective
May 10, 2013 at 12:13 am
Shouldn't be the first column binary? Or is the datatype precedence not applied here?
May 10, 2013 at 12:59 am
Good question, but Explanation is not completed or require more details.
I think hugo can help us.
Thanks
Vinay Kumar
-----------------------------------------------------------------
Keep Learning - Keep Growing !!!
May 10, 2013 at 1:08 am
Danny Ocean (5/10/2013)
Good question, but Explanation is not completed or require more details.I think hugo can help us.
Right Vinay 😛
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
May 10, 2013 at 1:16 am
Interesting question, thanks.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
May 10, 2013 at 1:29 am
Danny Ocean (5/10/2013)
Good question, but Explanation is not completed or require more details.I think hugo can help us.
I tried hard to explain it but I could not explain it will. I also had searched for where it is documented but could not find it 🙁 . Waiting if someone can put thought on this.
May 10, 2013 at 1:33 am
Good question!
Thanks
Igor Micev,My blog: www.igormicev.com
May 10, 2013 at 1:53 am
Good question ... went against my gut feel
May 10, 2013 at 1:54 am
Danny Ocean (5/10/2013)
Good question, but Explanation is not completed or require more details.I think hugo can help us.
Unfortunately, I can't. This is not consistent at all. In many other cases, SQL Server will complain when it has to conjure a data type for nulls out of thin air, and it would have made much more sense if it did so for this case as well.
(For example, compare "SELECT COALESCE(NULL, NULL);" with "SELECT COALESCE(NULL, CAST(NULL AS varchar(10)));")
I suspect that the reason it defaults to int is purely some internal implementation issue - int is probably first or last in some internal list that happens to be used here.
May 10, 2013 at 2:20 am
Interesting one, had to use sp_help though as I wasn't 100% sure! 😀
email: info@weekendwebdesign.co.uk
Personal Website: http://markallen.co.uk/
Business Website: https://www.weekendwebdesign.co.uk
May 10, 2013 at 3:24 am
WWDMark (5/10/2013)
Interesting one, had to use sp_help though as I wasn't 100% sure! 😀
+1
ww; Raghu
--
The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart.
May 10, 2013 at 3:42 am
I use this command SELECT INTO to create a table in development environment, then
I use my personal EXEC sp_createtable 'TempTab' to generate the script for creating the table
and in the batch/function/sp I insert the statement CREATE TABLE #t
In early releases of sqlserver (I do not know now), it seems that SELECT INTO in a transaction
may lock sys.objects and/or sys.columns.
May 10, 2013 at 4:08 am
Went with the gut feeling & got it right. Nice question. Thanks.
May 10, 2013 at 5:52 am
Hugo Kornelis (5/10/2013)
Danny Ocean (5/10/2013)
Good question, but Explanation is not completed or require more details.I think hugo can help us.
Unfortunately, I can't.
If Hugo doesn't get it, I don't feel bad for getting it wrong. 😀
ron
-----
a haiku...
NULL is not zero
NULL is not an empty string
NULL is the unknown
Viewing 15 posts - 1 through 15 (of 41 total)
You must be logged in to reply to this topic. Login to reply