October 22, 2018 at 1:22 pm
I have to calculate a new Label column for each combination of Start Date and End Date.
If start Date is Jan-18 then if End Date is Jan-18, then Label column is Month 1,
If Start Date is Jan-18 then if end Date is Feb-18 then Label column is Month 2,
If Start Date is Feb-18 then if end date is Feb-18, then Label columns is Month 1,
If Start Date is Feb-18 then if end date is March-18, then Label columns is Month 2 etc etc...
StartDate EndDate LabelColumn
Jan-18 Jan-18 Month 1
Jan-18 Feb-18 Month 2
Jan-18 Feb-18 Month 2
Jan-18 Mar-18 Month 3
Jan-18 Apr-18 Month 4
Feb-18 Feb-18 Month 1
Feb-18 Mar-18 Month 2
Feb-18 Mar-18 Month 2
Feb-18 Apr-18 Month 3
how do we do it using CTE?
October 22, 2018 at 1:43 pm
hegdesuchi - Monday, October 22, 2018 1:22 PMI have to calculate a new Label column for each combination of Start Date and End Date.
If start Date is Jan-18 then if End Date is Jan-18, then Label column is Month 1,
If Start Date is Jan-18 then if end Date is Feb-18 then Label column is Month 2,
If Start Date is Feb-18 then if end date is Feb-18, then Label columns is Month 1,
If Start Date is Feb-18 then if end date is March-18, then Label columns is Month 2 etc etc...StartDate EndDate LabelColumn
Jan-18 Jan-18 Month 1
Jan-18 Feb-18 Month 2
Jan-18 Feb-18 Month 2
Jan-18 Mar-18 Month 3
Jan-18 Apr-18 Month 4
Feb-18 Feb-18 Month 1
Feb-18 Mar-18 Month 2
Feb-18 Mar-18 Month 2
Feb-18 Apr-18 Month 3how do we do it using CTE?
Can we have some proper consumable sample data?
Whether it requires a CTE or not is another question, unless your requirement specifies that a CTE must be used, regardless of the optimum solution?
October 22, 2018 at 4:54 pm
hegdesuchi - Monday, October 22, 2018 1:22 PMI have to calculate a new Label column for each combination of Start Date and End Date.
If start Date is Jan-18 then if End Date is Jan-18, then Label column is Month 1,
If Start Date is Jan-18 then if end Date is Feb-18 then Label column is Month 2,
If Start Date is Feb-18 then if end date is Feb-18, then Label columns is Month 1,
If Start Date is Feb-18 then if end date is March-18, then Label columns is Month 2 etc etc...StartDate EndDate LabelColumn
Jan-18 Jan-18 Month 1
Jan-18 Feb-18 Month 2
Jan-18 Feb-18 Month 2
Jan-18 Mar-18 Month 3
Jan-18 Apr-18 Month 4
Feb-18 Feb-18 Month 1
Feb-18 Mar-18 Month 2
Feb-18 Mar-18 Month 2
Feb-18 Apr-18 Month 3how do we do it using CTE?
;with myTable (StartDate ,EndDate) AS
(SELECT * FROM (VALUES
('Jan-18', 'Jan-18'),
('Jan-18', 'Feb-18'),
('Jan-18', 'Feb-18'),
('Jan-18', 'Mar-18'),
('Jan-18', 'Apr-18'),
('Feb-18', 'Feb-18'),
('Feb-18', 'Mar-18'),
('Feb-18', 'Mar-18'),
('Feb-18', 'Apr-18')) T(A,B))
SELECT X.StartDate, X.StartDate, DATEDIFF(mm,'01-' + X.StartDate, '01-' + X.EndDate)+1
FROM mytable X
October 22, 2018 at 4:58 pm
;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
October 22, 2018 at 5:07 pm
Phil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
It's there as a statement separator 😉
October 23, 2018 at 7:21 am
Phil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
thank you very much. this works. 🙂
October 24, 2018 at 2:07 pm
Jonathan AC Roberts - Monday, October 22, 2018 5:07 PMPhil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
It's there as a statement separator 😉
The semi-colon problem goes way back to the very early days of Sybase SQL Server. In the ANSI ISO standard, it is used to terminate a statement. But Sybase got the BNF wrong and became a separator. Then when Microsoft began adding more standard features, it became an initiator in some places, such as the WITH. When I was on ANSI X3H2, one of our committee members had access to a really good parser and he would check any changes or additions we made to the language before the next meeting. We decided that the language was going to be and LALR (1) since that was pretty fancy in its day, but still easy enough that you could generate parser mechanically.
Please post DDL and follow ANSI/ISO standards when asking for help.
October 24, 2018 at 3:27 pm
jcelko212 32090 - Wednesday, October 24, 2018 2:07 PMJonathan AC Roberts - Monday, October 22, 2018 5:07 PMPhil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
It's there as a statement separator 😉
The semi-colon problem goes way back to the very early days of Sybase SQL Server. In the ANSI ISO standard, it is used to terminate a statement. But Sybase got the BNF wrong and became a separator. Then when Microsoft began adding more standard features, it became an initiator in some places, such as the WITH. When I was on ANSI X3H2, one of our committee members had access to a really good parser and he would check any changes or additions we made to the language before the next meeting. We decided that the language was going to be and LALR (1) since that was pretty fancy in its day, but still easy enough that you could generate parser mechanically.
It was never an initiator (and I prefer beginninator). That occurred due to piss-poor examples in BOL when CTEs were first introduced. The documentation even stated that the PREVIOUS statement must be terminated by a semicolon. Ever since then it has become a crutch to "insure" that the previous statement is terminated without actually terminating the previous statement with a semicolon.
Sorry, but a big pet peeve of mine.
October 24, 2018 at 4:12 pm
Lynn Pettis - Wednesday, October 24, 2018 3:27 PMIt was never an initiator (and I prefer beginninator).
Wouldn't the opposite of a beginnator be an endator?
Initiator is a better antonym.
October 24, 2018 at 5:06 pm
Lynn Pettis - Wednesday, October 24, 2018 3:27 PMjcelko212 32090 - Wednesday, October 24, 2018 2:07 PMJonathan AC Roberts - Monday, October 22, 2018 5:07 PMPhil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
It's there as a statement separator 😉
The semi-colon problem goes way back to the very early days of Sybase SQL Server. In the ANSI ISO standard, it is used to terminate a statement. But Sybase got the BNF wrong and became a separator. Then when Microsoft began adding more standard features, it became an initiator in some places, such as the WITH. When I was on ANSI X3H2, one of our committee members had access to a really good parser and he would check any changes or additions we made to the language before the next meeting. We decided that the language was going to be and LALR (1) since that was pretty fancy in its day, but still easy enough that you could generate parser mechanically.
It was never an initiator (and I prefer beginninator). That occurred due to piss-poor examples in BOL when CTEs were first introduced. The documentation even stated that the PREVIOUS statement must be terminated by a semicolon. Ever since then it has become a crutch to "insure" that the previous statement is terminated without actually terminating the previous statement with a semicolon.
Sorry, but a big pet peeve of mine.
I use ;WITH whenever it's allowed, because it helps prevent future errors. Since T-SQL doesn't require statement terminators in most cases, it's quite common to leave them off. Even if you spend (i.e. waste) valuable time adding ; terminators to the previous statement, a later code change could cause a different previous statement. Thus, yes, it is safer just to code the starting ;. And if the previous statement does end in ;, the leading ; causes no issue anyway.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
October 24, 2018 at 6:34 pm
ScottPletcher - Wednesday, October 24, 2018 5:06 PMLynn Pettis - Wednesday, October 24, 2018 3:27 PMjcelko212 32090 - Wednesday, October 24, 2018 2:07 PMJonathan AC Roberts - Monday, October 22, 2018 5:07 PMPhil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
It's there as a statement separator 😉
The semi-colon problem goes way back to the very early days of Sybase SQL Server. In the ANSI ISO standard, it is used to terminate a statement. But Sybase got the BNF wrong and became a separator. Then when Microsoft began adding more standard features, it became an initiator in some places, such as the WITH. When I was on ANSI X3H2, one of our committee members had access to a really good parser and he would check any changes or additions we made to the language before the next meeting. We decided that the language was going to be and LALR (1) since that was pretty fancy in its day, but still easy enough that you could generate parser mechanically.
It was never an initiator (and I prefer beginninator). That occurred due to piss-poor examples in BOL when CTEs were first introduced. The documentation even stated that the PREVIOUS statement must be terminated by a semicolon. Ever since then it has become a crutch to "insure" that the previous statement is terminated without actually terminating the previous statement with a semicolon.
Sorry, but a big pet peeve of mine.
I use ;WITH whenever it's allowed, because it helps prevent future errors. Since T-SQL doesn't require statement terminators in most cases, it's quite common to leave them off. Even if you spend (i.e. waste) valuable time adding ; terminators to the previous statement, a later code change could cause a different previous statement. Thus, yes, it is safer just to code the starting ;. And if the previous statement does end in ;, the leading ; causes no issue anyway.
Since not using a semicolon to terminate a "statement" has been deprecated for some time, I use a semicolon to properly terminate all statements so that when the deprecation turns into a requirement, I won't have any such problems. Hopefully, I'll live long enough to see that happen so I can hear a good part of the world scream when it becomes a requirement. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
October 25, 2018 at 2:02 am
Jeff Moden - Wednesday, October 24, 2018 6:34 PMScottPletcher - Wednesday, October 24, 2018 5:06 PMLynn Pettis - Wednesday, October 24, 2018 3:27 PMjcelko212 32090 - Wednesday, October 24, 2018 2:07 PMJonathan AC Roberts - Monday, October 22, 2018 5:07 PMPhil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
It's there as a statement separator 😉
The semi-colon problem goes way back to the very early days of Sybase SQL Server. In the ANSI ISO standard, it is used to terminate a statement. But Sybase got the BNF wrong and became a separator. Then when Microsoft began adding more standard features, it became an initiator in some places, such as the WITH. When I was on ANSI X3H2, one of our committee members had access to a really good parser and he would check any changes or additions we made to the language before the next meeting. We decided that the language was going to be and LALR (1) since that was pretty fancy in its day, but still easy enough that you could generate parser mechanically.
It was never an initiator (and I prefer beginninator). That occurred due to piss-poor examples in BOL when CTEs were first introduced. The documentation even stated that the PREVIOUS statement must be terminated by a semicolon. Ever since then it has become a crutch to "insure" that the previous statement is terminated without actually terminating the previous statement with a semicolon.
Sorry, but a big pet peeve of mine.
I use ;WITH whenever it's allowed, because it helps prevent future errors. Since T-SQL doesn't require statement terminators in most cases, it's quite common to leave them off. Even if you spend (i.e. waste) valuable time adding ; terminators to the previous statement, a later code change could cause a different previous statement. Thus, yes, it is safer just to code the starting ;. And if the previous statement does end in ;, the leading ; causes no issue anyway.
Since not using a semicolon to terminate a "statement" has been deprecated for some time, I use a semicolon to properly terminate all statements so that when the deprecation turns into a requirement, I won't have any such problems. Hopefully, I'll live long enough to see that happen so I can hear a good part of the world scream when it becomes a requirement. 😀
Jeff, do you use IF BEGIN END?
If so do you terminate the BEGIN and END with semi colon?
Just curious 🙂
Far away is close at hand in the images of elsewhere.
Anon.
October 25, 2018 at 7:54 am
David Burrows - Thursday, October 25, 2018 2:02 AMJeff Moden - Wednesday, October 24, 2018 6:34 PMScottPletcher - Wednesday, October 24, 2018 5:06 PMLynn Pettis - Wednesday, October 24, 2018 3:27 PMjcelko212 32090 - Wednesday, October 24, 2018 2:07 PMJonathan AC Roberts - Monday, October 22, 2018 5:07 PMPhil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
It's there as a statement separator 😉
The semi-colon problem goes way back to the very early days of Sybase SQL Server. In the ANSI ISO standard, it is used to terminate a statement. But Sybase got the BNF wrong and became a separator. Then when Microsoft began adding more standard features, it became an initiator in some places, such as the WITH. When I was on ANSI X3H2, one of our committee members had access to a really good parser and he would check any changes or additions we made to the language before the next meeting. We decided that the language was going to be and LALR (1) since that was pretty fancy in its day, but still easy enough that you could generate parser mechanically.
It was never an initiator (and I prefer beginninator). That occurred due to piss-poor examples in BOL when CTEs were first introduced. The documentation even stated that the PREVIOUS statement must be terminated by a semicolon. Ever since then it has become a crutch to "insure" that the previous statement is terminated without actually terminating the previous statement with a semicolon.
Sorry, but a big pet peeve of mine.
I use ;WITH whenever it's allowed, because it helps prevent future errors. Since T-SQL doesn't require statement terminators in most cases, it's quite common to leave them off. Even if you spend (i.e. waste) valuable time adding ; terminators to the previous statement, a later code change could cause a different previous statement. Thus, yes, it is safer just to code the starting ;. And if the previous statement does end in ;, the leading ; causes no issue anyway.
Since not using a semicolon to terminate a "statement" has been deprecated for some time, I use a semicolon to properly terminate all statements so that when the deprecation turns into a requirement, I won't have any such problems. Hopefully, I'll live long enough to see that happen so I can hear a good part of the world scream when it becomes a requirement. 😀
Jeff, do you use IF BEGIN END?
If so do you terminate the BEGIN and END with semi colon?
Just curious 🙂
Yes to both. You do have to be a little careful when using ELSE. As with anything else the code parser doesn't currently check, I might miss a semicolon here or there but I try not to. It's good practice for what's on the horizon. Heh.... I've actually found an alternate use for semicolons... I use it as a marker to indicate that I'm done writing that particular piece of code and have tested it. While developing, I use a --todo comment to indicate that I may not be done with it and I can easily do a search for --todo to easily find such things. I don't "forward" the code until there are no --todo's left in the code.
BTW.... officially, I hate the use of semicolons and I hate the use of things that require "line continuation". But not using them is a bit like spitting into the wind because of the looming deprecation threat and the fact that they already require previous statement termination in order to use CTEs that follow.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 25, 2018 at 8:21 am
SQL Prompt can do all of the terminator legwork for you.
October 25, 2018 at 8:30 am
Jeff Moden - Thursday, October 25, 2018 7:54 AMDavid Burrows - Thursday, October 25, 2018 2:02 AMJeff Moden - Wednesday, October 24, 2018 6:34 PMScottPletcher - Wednesday, October 24, 2018 5:06 PMLynn Pettis - Wednesday, October 24, 2018 3:27 PMjcelko212 32090 - Wednesday, October 24, 2018 2:07 PMJonathan AC Roberts - Monday, October 22, 2018 5:07 PMPhil Parkin - Monday, October 22, 2018 4:58 PM;with myTable (StartDate ,EndDate) AS
That semicolon 'initiator' is there just to wind us up, right? 🙂
It's there as a statement separator 😉
The semi-colon problem goes way back to the very early days of Sybase SQL Server. In the ANSI ISO standard, it is used to terminate a statement. But Sybase got the BNF wrong and became a separator. Then when Microsoft began adding more standard features, it became an initiator in some places, such as the WITH. When I was on ANSI X3H2, one of our committee members had access to a really good parser and he would check any changes or additions we made to the language before the next meeting. We decided that the language was going to be and LALR (1) since that was pretty fancy in its day, but still easy enough that you could generate parser mechanically.
It was never an initiator (and I prefer beginninator). That occurred due to piss-poor examples in BOL when CTEs were first introduced. The documentation even stated that the PREVIOUS statement must be terminated by a semicolon. Ever since then it has become a crutch to "insure" that the previous statement is terminated without actually terminating the previous statement with a semicolon.
Sorry, but a big pet peeve of mine.
I use ;WITH whenever it's allowed, because it helps prevent future errors. Since T-SQL doesn't require statement terminators in most cases, it's quite common to leave them off. Even if you spend (i.e. waste) valuable time adding ; terminators to the previous statement, a later code change could cause a different previous statement. Thus, yes, it is safer just to code the starting ;. And if the previous statement does end in ;, the leading ; causes no issue anyway.
Since not using a semicolon to terminate a "statement" has been deprecated for some time, I use a semicolon to properly terminate all statements so that when the deprecation turns into a requirement, I won't have any such problems. Hopefully, I'll live long enough to see that happen so I can hear a good part of the world scream when it becomes a requirement. 😀
Jeff, do you use IF BEGIN END?
If so do you terminate the BEGIN and END with semi colon?
Just curious 🙂Yes to both. You do have to be a little careful when using ELSE. As with anything else the code parser doesn't currently check, I might miss a semicolon here or there but I try not to. It's good practice for what's on the horizon. Heh.... I've actually found an alternate use for semicolons... I use it as a marker to indicate that I'm done writing that particular piece of code and have tested it. While developing, I use a --todo comment to indicate that I may not be done with it and I can easily do a search for --todo to easily find such things. I don't "forward" the code until there are no --todo's left in the code.
BTW.... officially, I hate the use of semicolons and I hate the use of things that require "line continuation". But not using them is a bit like spitting into the wind because of the looming deprecation threat and the fact that they already require previous statement termination in order to use CTEs that follow.
And there are statements, MERGE is the only one I can think of, that requires them to be terminated with a semicolon.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply