April 4, 2013 at 9:06 am
i was trying to solve an online test... and i stopped here... i tried looking at the newly introduced functions of sql server 2012 but could n't find an answer... hope i will get some answer here..
select blank (GETUTCDATE(), 'blank') as Result
the answer is
Result
Monday April 08
you will have to replace the 'blank' with some function or key word which i couldn't figure out..
thanks in advance
--Pra:-):-)--------------------------------------------------------------------------------
April 4, 2013 at 9:08 am
prathibha_aviator (4/4/2013)
i was trying to solve an online test... and i stopped here... i tried looking at the newly introduced functions of sql server 2012 but could n't find an answer... hope i will get some answer here..
select blank (GETUTCDATE(), 'blank') as Result
the answer is
Result
Monday April 08
you will have to replace the 'blank' with some function or key word which i couldn't figure out..
thanks in advance
huh? I am not sure what the question is here.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
April 4, 2013 at 9:12 am
mm, I have to replace the 'blank' term which appeared twice with some functions or keywords like PARSE, convert or CAST to get the result like that.. I couldn't figure out what would get me a result like
Monday April 08
pls find the attachment if u want see how it looks like
--Pra:-):-)--------------------------------------------------------------------------------
April 4, 2013 at 9:42 am
i though blank() was a new SQL 2012 function, haha; pasted it to test and everything!
Lowell
April 4, 2013 at 9:45 am
[:)] [:)] [:)] [:)]
--Pra:-):-)--------------------------------------------------------------------------------
April 4, 2013 at 11:08 am
I don't think this is doable in SQL just by replacing a simple function/format for the blanks. From a cursory look, it appears more to be in MYSQL format, which has a function called DATE_PART. For your case, it will be simply...
SELECT DATE_PART (<<Date>>, '%W %M %d')
Are you sure it was an "MS SQL Test", and not MYSQL Test? Just wondering 😛
- Rex
April 4, 2013 at 12:01 pm
Actually, lookup FORMAT in BOL for SQL Server 2012.
January 19, 2019 at 5:24 pm
I know this is an old post but it reminds me of why I hate the tests that people are prone to writing. I actually had to stop and think about this because I wouldn't memorize the formatting literal for FORMAT if my life depended on it because I won't ever use it until the fix the awful performance issue with this function. Yep... I can get the FORMAT part right... just not the bloody case sensitive formatting string that goes with it.
If someone was able to add the correct formatting string, I might actually take points away from them because that would mean they've used it enough to have had cause to memorize it and that would also mean that either they don't care about the performance problems or they don't know about them. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2019 at 10:20 am
Jeff Moden - Saturday, January 19, 2019 5:24 PMI know this is an old post but it reminds me of why I hate the tests that people are prone to writing. I actually had to stop and think about this because I wouldn't memorize the formatting literal for FORMAT if my life depended on it because I won't ever use it until the fix the awful performance issue with this function. Yep... I can get the FORMAT part right... just not the bloody case sensitive formatting string that goes with it.If someone was able to add the correct formatting string, I might actually take points away from them because that would mean they've used it enough to have had cause to memorize it and that would also mean that either they don't care about the performance problems or they don't know about them. 😀
Or - they code in .NET quite frequently and use it in that code, which then leads them to using it in SQL Server because it is more familiar than using CONVERT. This could be someone coding in SSRS or SSIS also - although that probably isn't as frequent.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
January 20, 2019 at 12:17 pm
Jeffrey Williams 3188 - Sunday, January 20, 2019 10:20 AMJeff Moden - Saturday, January 19, 2019 5:24 PMI know this is an old post but it reminds me of why I hate the tests that people are prone to writing. I actually had to stop and think about this because I wouldn't memorize the formatting literal for FORMAT if my life depended on it because I won't ever use it until the fix the awful performance issue with this function. Yep... I can get the FORMAT part right... just not the bloody case sensitive formatting string that goes with it.If someone was able to add the correct formatting string, I might actually take points away from them because that would mean they've used it enough to have had cause to memorize it and that would also mean that either they don't care about the performance problems or they don't know about them. 😀
Or - they code in .NET quite frequently and use it in that code, which then leads them to using it in SQL Server because it is more familiar than using CONVERT. This could be someone coding in SSRS or SSIS also - although that probably isn't as frequent.
Yep... I get all that. One has to wonder that since the FORMAT function in SQL Server actually uses the .NET function behind the scenes, what kind of performance problems are front-enders having on large volumes of data when they use it in .NET based programming languages?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2019 at 1:48 pm
Jeff Moden - Sunday, January 20, 2019 12:17 PMJeffrey Williams 3188 - Sunday, January 20, 2019 10:20 AMJeff Moden - Saturday, January 19, 2019 5:24 PMI know this is an old post but it reminds me of why I hate the tests that people are prone to writing. I actually had to stop and think about this because I wouldn't memorize the formatting literal for FORMAT if my life depended on it because I won't ever use it until the fix the awful performance issue with this function. Yep... I can get the FORMAT part right... just not the bloody case sensitive formatting string that goes with it.If someone was able to add the correct formatting string, I might actually take points away from them because that would mean they've used it enough to have had cause to memorize it and that would also mean that either they don't care about the performance problems or they don't know about them. 😀
Or - they code in .NET quite frequently and use it in that code, which then leads them to using it in SQL Server because it is more familiar than using CONVERT. This could be someone coding in SSRS or SSIS also - although that probably isn't as frequent.
Yep... I get all that. One has to wonder that since the FORMAT function in SQL Server actually uses the .NET function behind the scenes, what kind of performance problems are front-enders having on large volumes of data when they use it in .NET based programming languages?
Or did Microsoft just do a poor job at implementing the function in CLR?
January 20, 2019 at 3:07 pm
Lynn Pettis - Sunday, January 20, 2019 1:48 PMJeff Moden - Sunday, January 20, 2019 12:17 PMJeffrey Williams 3188 - Sunday, January 20, 2019 10:20 AMJeff Moden - Saturday, January 19, 2019 5:24 PMI know this is an old post but it reminds me of why I hate the tests that people are prone to writing. I actually had to stop and think about this because I wouldn't memorize the formatting literal for FORMAT if my life depended on it because I won't ever use it until the fix the awful performance issue with this function. Yep... I can get the FORMAT part right... just not the bloody case sensitive formatting string that goes with it.If someone was able to add the correct formatting string, I might actually take points away from them because that would mean they've used it enough to have had cause to memorize it and that would also mean that either they don't care about the performance problems or they don't know about them. 😀
Or - they code in .NET quite frequently and use it in that code, which then leads them to using it in SQL Server because it is more familiar than using CONVERT. This could be someone coding in SSRS or SSIS also - although that probably isn't as frequent.
Yep... I get all that. One has to wonder that since the FORMAT function in SQL Server actually uses the .NET function behind the scenes, what kind of performance problems are front-enders having on large volumes of data when they use it in .NET based programming languages?
Or did Microsoft just do a poor job at implementing the function in CLR?
Dunno for sure. I probably won't know unless someone else does a test. I don't even know how to fire up a .Net programming environment anymore so it's not likely that I'll be the one to do a test. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
January 21, 2019 at 2:32 pm
Jeff Moden - Sunday, January 20, 2019 3:07 PMLynn Pettis - Sunday, January 20, 2019 1:48 PMJeff Moden - Sunday, January 20, 2019 12:17 PMJeffrey Williams 3188 - Sunday, January 20, 2019 10:20 AMJeff Moden - Saturday, January 19, 2019 5:24 PMI know this is an old post but it reminds me of why I hate the tests that people are prone to writing. I actually had to stop and think about this because I wouldn't memorize the formatting literal for FORMAT if my life depended on it because I won't ever use it until the fix the awful performance issue with this function. Yep... I can get the FORMAT part right... just not the bloody case sensitive formatting string that goes with it.If someone was able to add the correct formatting string, I might actually take points away from them because that would mean they've used it enough to have had cause to memorize it and that would also mean that either they don't care about the performance problems or they don't know about them. 😀
Or - they code in .NET quite frequently and use it in that code, which then leads them to using it in SQL Server because it is more familiar than using CONVERT. This could be someone coding in SSRS or SSIS also - although that probably isn't as frequent.
Yep... I get all that. One has to wonder that since the FORMAT function in SQL Server actually uses the .NET function behind the scenes, what kind of performance problems are front-enders having on large volumes of data when they use it in .NET based programming languages?
Or did Microsoft just do a poor job at implementing the function in CLR?
Dunno for sure. I probably won't know unless someone else does a test. I don't even know how to fire up a .Net programming environment anymore so it's not likely that I'll be the one to do a test. 😀
I am lucky that I can spell CLR, so neither will I in the near future.
January 21, 2019 at 2:49 pm
Lynn Pettis - Monday, January 21, 2019 2:32 PMJeff Moden - Sunday, January 20, 2019 3:07 PMLynn Pettis - Sunday, January 20, 2019 1:48 PMJeff Moden - Sunday, January 20, 2019 12:17 PMJeffrey Williams 3188 - Sunday, January 20, 2019 10:20 AMJeff Moden - Saturday, January 19, 2019 5:24 PMI know this is an old post but it reminds me of why I hate the tests that people are prone to writing. I actually had to stop and think about this because I wouldn't memorize the formatting literal for FORMAT if my life depended on it because I won't ever use it until the fix the awful performance issue with this function. Yep... I can get the FORMAT part right... just not the bloody case sensitive formatting string that goes with it.If someone was able to add the correct formatting string, I might actually take points away from them because that would mean they've used it enough to have had cause to memorize it and that would also mean that either they don't care about the performance problems or they don't know about them. 😀
Or - they code in .NET quite frequently and use it in that code, which then leads them to using it in SQL Server because it is more familiar than using CONVERT. This could be someone coding in SSRS or SSIS also - although that probably isn't as frequent.
Yep... I get all that. One has to wonder that since the FORMAT function in SQL Server actually uses the .NET function behind the scenes, what kind of performance problems are front-enders having on large volumes of data when they use it in .NET based programming languages?
Or did Microsoft just do a poor job at implementing the function in CLR?
Dunno for sure. I probably won't know unless someone else does a test. I don't even know how to fire up a .Net programming environment anymore so it's not likely that I'll be the one to do a test. 😀
I am lucky that I can spell CLR, so neither will I in the near future.
I could easily put together a test in a VS project but it would horribly unrealistic. I can't even imagine a front end with a million rows of data. I don't care how fast your sql is, the performance to render to the UI is going to suck the life of everything including the person waiting for it. And of course the performance would vary significantly between a windows app and a web app.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
January 22, 2019 at 11:52 am
Sean Lange - Monday, January 21, 2019 2:49 PMI could easily put together a test in a VS project but it would horribly unrealistic. I can't even imagine a front end with a million rows of data. I don't care how fast your sql is, the performance to render to the UI is going to suck the life of everything including the person waiting for it. And of course the performance would vary significantly between a windows app and a web app.
The only reason why I'd do a million row test is to have enough to actually measure the outcome with. I agree that if a UI is having to address a million rows, then Murphy's half brother(Sum Ting Wong) is having a field day. It would just be to see if the front-end version would be a part of the "Death by a Thousand Cuts" and all such problematic code lends itself to.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply