July 12, 2018 at 9:16 am
Actually according to Microsoft it's not required at all. Their own example doesn't use it.
July 12, 2018 at 9:17 am
Sean Lange - Thursday, July 12, 2018 8:04 AMlmalatesta - Thursday, July 12, 2018 7:49 AMSean Lange - Thursday, July 12, 2018 7:15 AMI don't know why the coding style of starting a cte became to be but it causes so much confusion.It came to be because Microsoft made the decision to not enforce the ANSI SQL-92 standards in SQL Server that require each valid SQL statement to be terminated with a semicolon.
So putting a semicolon at the beginning of any CTE became a bit of defensive programming for those who have been around the block and one of those things you just do for people that haven't.
Even worse than not enforcing it is that they DO enforce it but not for everything. Only some statements require the previous one to be properly terminated and only some statements require that they themselves are terminated. So much sloppy code out there because of the lack of requirements for so long they are really kind of stuck. They want to enforce standards but it would break so much code out there.
And some of it will be there own code.
July 12, 2018 at 9:19 am
PurpleLady - Thursday, July 12, 2018 9:16 AMActually according to Microsoft it's not required at all. Their own example doesn't use it.
That is the newer examples. The older examples in Books Online when CTE's first became available had the semicolon right before the WITH even though the documentation said that the previous statement had to be terminated with a semicolon.
July 12, 2018 at 9:25 am
Sean Lange - Thursday, July 12, 2018 8:04 AMEven worse than not enforcing it is that they DO enforce it but not for everything. Only some statements require the previous one to be properly terminated and only some statements require that they themselves are terminated.
Leaving statement terminators out was officially deprecated as of SQL Server 2008. One should expect syntax and functionality introduced or updated since then to be dependent on the previously statement being properly terminated.
July 12, 2018 at 9:27 am
lmalatesta - Thursday, July 12, 2018 9:25 AMSean Lange - Thursday, July 12, 2018 8:04 AMEven worse than not enforcing it is that they DO enforce it but not for everything. Only some statements require the previous one to be properly terminated and only some statements require that they themselves are terminated.Leaving statement terminators out was officially deprecated as of SQL Server 2008. One should expect syntax and functionality introduced or updated since then to be dependent on the previously statement being properly terminated.
Yea, good luck with that happening. Human nature, apparently, to do just what is necessary and nothing more for many people.
July 12, 2018 at 9:33 am
Lynn Pettis - Thursday, July 12, 2018 9:27 AMHuman nature, apparently, to do just what is necessary and nothing more for many people.
I fear you overestimate human nature.
July 12, 2018 at 10:18 am
Steve Jones - SSC Editor - Thursday, July 12, 2018 7:58 AMlmalatesta - Thursday, July 12, 2018 7:45 AMThe smart money is on Microsoft never making statement terminators mandatory. The amount of T-SQL code that would break is mind boggling.Not taking that bet. They'll never require it
If they do then it will be configurable via some sort of database or server option
SET ALLOW_SLOPPY_CODE ON
July 12, 2018 at 12:02 pm
lmalatesta - Thursday, July 12, 2018 9:25 AMLeaving statement terminators out was officially deprecated as of SQL Server 2008. One should expect syntax and functionality introduced or updated since then to be dependent on the previously statement being properly terminated.
One can never expect this in older code. If you are making new code, I'd agree. All statements ought to be terminated, but for people working with T-SQL for more than 5 years, they likely won't.
July 12, 2018 at 12:04 pm
Toreador - Thursday, July 12, 2018 10:18 AMIf they do then it will be configurable via some sort of database or server option
SET ALLOW_SLOPPY_CODE ON
Erland Skomerskag had a suggestion in Conect for SET STRICT CHECKS or something like that, to start forcing better habits. Not sure they'll add it.
July 12, 2018 at 12:39 pm
Steve Jones - SSC Editor - Thursday, July 12, 2018 12:02 PMlmalatesta - Thursday, July 12, 2018 9:25 AMLeaving statement terminators out was officially deprecated as of SQL Server 2008. One should expect syntax and functionality introduced or updated since then to be dependent on the previously statement being properly terminated.One can never expect this in older code. If you are making new code, I'd agree. All statements ought to be terminated, but for people working with T-SQL for more than 5 years, they likely won't.
I think we're talking at cross purposes here. I was talking about new syntax and functionality in SQL Server. For example, Microsoft introducing CTE syntax that requires the previous statement be terminated.
I'd largely agree that no one should expect T-SQL programmers to properly terminate every statement. In my experience only SQL folks from an Oracle or Postgres background even try use semicolons in T-SQL.
July 12, 2018 at 12:48 pm
lmalatesta - Thursday, July 12, 2018 12:39 PMI think we're talking at cross purposes here. I was talking about new syntax and functionality in SQL Server. For example, Microsoft introducing CTE syntax that requires the previous statement be terminated.I'd largely agree that no one should expect T-SQL programmers to properly terminate every statement. In my experience only SQL folks from an Oracle or Postgres background even try use semicolons in T-SQL.
Nope, I have been writing T-SQL for over 20 years and I have tried very hard to be sure to semicolons in my code. I may fail at times, but that is what I strive for and it made moving to CTE's when they became available easy to work with as it didn't mean I had to change my habits.
July 12, 2018 at 4:26 pm
Bob Razumich - Wednesday, July 11, 2018 9:51 PMI am so looking forward to the arguments about where the semicolon should go exactly.
No arguments. The semicolon should always begin the line immediately following the statement it terminates, and it should be the only thing on the line:
SELECT 1
FROM dbo.MyTable
;
SELECT 2
FROM dbo.YourTable
;
This way it's clear to which statement the semicolon belongs, but it doesn't get in the way of adding more code to the statement:
SELECT 1
FROM dbo.MyTable
WHERE A = 1
;
SELECT 2
FROM dbo.YourTable
;
July 12, 2018 at 4:40 pm
sknox - Thursday, July 12, 2018 4:26 PMBob Razumich - Wednesday, July 11, 2018 9:51 PMI am so looking forward to the arguments about where the semicolon should go exactly.No arguments. The semicolon should always begin the line immediately following the statement it terminates, and it should be the only thing on the line:
SELECT 1
FROM dbo.MyTable
;SELECT 2
FROM dbo.YourTable
;This way it's clear to which statement the semicolon belongs, but it doesn't get in the way of adding more code to the statement:
SELECT 1
FROM dbo.MyTable
WHERE A = 1
;SELECT 2
FROM dbo.YourTable
;
I do that while developing code, but move it to the end of each statement when development is completed.
July 12, 2018 at 4:47 pm
Lynn Pettis - Thursday, July 12, 2018 4:40 PMI do that while developing code, but move it to the end of each statement when development is completed.
"when development is completed."
I wish I had that luxury! ; )
July 12, 2018 at 5:23 pm
sknox - Thursday, July 12, 2018 4:47 PM"when development is completed."
I wish I had that luxury! ; )
Well, at some point things have to go into production. My problem is that most of the things I work on come from production and I have to fix them. I don't see the poor code during development, test, qa, uat.
Viewing 15 posts - 16 through 30 (of 32 total)
You must be logged in to reply to this topic. Login to reply