September 21, 2012 at 5:02 am
I guess I found some shorter and obscure enough one!
SELECT EXP($)
It's only 13 characters long and no numbers :hehe:
September 21, 2012 at 5:30 am
Still a tie then:
SELECT DAY($)
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
September 21, 2012 at 5:34 am
dwain.c (9/21/2012)
Still a tie then:
SELECT DAY($)
I thought the Cup is given to whoever comes first...
:hehe:
September 21, 2012 at 6:41 am
David Moutray (9/20/2012)
Well, let's be charitable and assume that he is suitably embarrassed by his behavior.
Heh... I WAS being charitable. So far as him being embarrassed goes... probably not because he has the answers he was looking for. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2012 at 6:52 am
Eugene Elutin (9/21/2012)
dwain.c (9/21/2012)
Still a tie then:
SELECT DAY($)
I thought the Cup is given to whoever comes first...
:hehe:
I'll settle for an honorable mention.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
September 21, 2012 at 7:01 am
SELECT COS($)
Will do the same, but it's to obvious...
I think the harder question would be: How to return 4 without using number in SELECT,
finding SELECT LEN($), would be a bit more trickier than applying math function...
😀
September 21, 2012 at 7:07 am
Eugene Elutin (9/21/2012)
SELECT COS($)Will do the same, but it's to obvious...
I think the harder question would be: How to return 4 without using number in SELECT,
finding SELECT LEN($), would be a bit more trickier than applying math function...
😀
And the beauty of the problem with 4 as the result is that there may only be one solution.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
September 21, 2012 at 7:17 am
Eugene Elutin (9/21/2012)
dwain.c (9/21/2012)
Still a tie then:
SELECT DAY($)
I thought the Cup is given to whoever comes first...
:hehe:
No if second one hits you on the head with a frypan and runs away with the trophy 😀
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.September 21, 2012 at 7:30 am
dwain.c (9/21/2012)
Eugene Elutin (9/21/2012)
SELECT COS($)Will do the same, but it's to obvious...
I think the harder question would be: How to return 4 without using number in SELECT,
finding SELECT LEN($), would be a bit more trickier than applying math function...
😀
And the beauty of the problem with 4 as the result is that there may only be one solution.
Not really, there are few variations:
SELECT LEN(£)
SELECT LEN(€)
...
:hehe:
September 21, 2012 at 9:00 am
Hmm, I couldn't think of anything shorter. I wanted to find a way to implicitly convert PI to a bit, but apparently there's no bit literal in SQL Server.
I went for convoluted instead:
SELECT Round(SQRT(PI()),$,@@SPID)
September 23, 2012 at 9:07 am
I think the answer P.D. is after is [font="Courier New"]SELECT COUNT(*)[/font] It's not the shortest, though.
edit: Sorry I see 'mickyT' already mentioned this.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
September 24, 2012 at 9:45 am
select count(*)
too late ha ha ha
September 24, 2012 at 12:08 pm
are procedures banned from this, ie you can only use a select?
you could do it in a single characet then:
CREATE PROC z
AS
SELECT cos('')
GO
z
Lowell
September 24, 2012 at 1:17 pm
Shame there isn't implicit conversion for money to int in the following
SELECT -(~$)
It would have made a good answer
September 24, 2012 at 1:33 pm
Yes! That would have been great. I don't think you even need the parentheses. That answer would be nigh unbeatable. (Too bad it doesn't work. :hehe:)
Viewing 15 posts - 31 through 45 (of 46 total)
You must be logged in to reply to this topic. Login to reply