cphite (11/14/2014)
What purpose does making it mandatory actually serve?
Simplifies the parser, makes it easier to extend the language. T-SQL's getting to the point where it's hard for the parser to tell statements apart consistently, in all cases. Hence the increasing requirement for ; to delimit statements. Less parsing bugs, easier to add new language features.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
GilaMonster (11/15/2014)
cphite (11/14/2014)
What purpose does making it mandatory actually serve?Simplifies the parser, makes it easier to extend the language. T-SQL's getting to the point where it's hard for the parser to tell statements apart consistently, in all cases. Hence the increasing requirement for ; to delimit statements. Less parsing bugs, easier to add new language features.
Fair enough... just hoping they have a good tool for updating existing code... I have a LOT of code...
I've decided to (try to) adopt the trailing semicolon... it still feels weird.
Koen Verbeeck (11/14/2014)
Jason-299789 (11/14/2014)
Koen Verbeeck (11/13/2014)
The CTE should be followed by a SELECT, INSERT, UPDATE or DELETE statement, not by an IF statement.ps: the semicolon is a statement terminator, it has no business being there before WITH.
The problem is that 90% of developers don't use the ';' on every line of code, I know I don't, especially in a declaration area, so putting the ';' at the start of the WITH has started to become common practice.
90% of the people are wrong
And 75% of statistics are made up!
_______________________________________________________________
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/
Sean Lange (11/19/2014)
Koen Verbeeck (11/14/2014)
Jason-299789 (11/14/2014)
Koen Verbeeck (11/13/2014)
The CTE should be followed by a SELECT, INSERT, UPDATE or DELETE statement, not by an IF statement.ps: the semicolon is a statement terminator, it has no business being there before WITH.
The problem is that 90% of developers don't use the ';' on every line of code, I know I don't, especially in a declaration area, so putting the ';' at the start of the WITH has started to become common practice.
90% of the people are wrong
And 75% of statistics are made up!
12 in 14 scientific studies prove the fact that you can make any claim, as long as you use precise numbers.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
cphite (11/19/2014)
GilaMonster (11/15/2014)
cphite (11/14/2014)
What purpose does making it mandatory actually serve?Simplifies the parser, makes it easier to extend the language. T-SQL's getting to the point where it's hard for the parser to tell statements apart consistently, in all cases. Hence the increasing requirement for ; to delimit statements. Less parsing bugs, easier to add new language features.
Fair enough... just hoping they have a good tool for updating existing code...
Look in the mirror, there's your good tool.
Seriously, start updating your code, as you change a proc, go through it and add the ;. Do that consistently and by the time it becomes mandatory (whenever that is), there won't be much to change.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
I have several hundred reports that I maintain over various systems... many of them based on one or more stored procedures, many others with one or more SQL scripts embedded in the .RDL that rarely change and that I have no reason to touch other than to deal with this particular issue. It's going to be a ton of additional work.
So yeah, I get what you're saying and that was pretty much what I had in mind... but it's still going to be a ton of additional work. There is a lot of code that I or my team doesn't necessarily have a reason to touch other than to add semicolons.
cphite (11/19/2014)
I have several hundred reports that I maintain over various systems... many of them based on one or more stored procedures, many others with one or more SQL scripts embedded in the .RDL that rarely change and that I have no reason to touch other than to deal with this particular issue. It's going to be a ton of additional work.So yeah, I get what you're saying and that was pretty much what I had in mind... but it's still going to be a ton of additional work. There is a lot of code that I or my team doesn't necessarily have a reason to touch other than to add semicolons.
Gail didn't suggest changing these for the sake of adding semicolons. She suggested that when you have to change existing code that you should also add semicolons as part of that update. Make that part of your ongoing process when you update code and it will minimize the effort when it becomes mandatory.
_______________________________________________________________
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/
Sean Lange (11/19/2014)
cphite (11/19/2014)
I have several hundred reports that I maintain over various systems... many of them based on one or more stored procedures, many others with one or more SQL scripts embedded in the .RDL that rarely change and that I have no reason to touch other than to deal with this particular issue. It's going to be a ton of additional work.So yeah, I get what you're saying and that was pretty much what I had in mind... but it's still going to be a ton of additional work. There is a lot of code that I or my team doesn't necessarily have a reason to touch other than to add semicolons.
Gail didn't suggest changing these for the sake of adding semicolons. She suggested that when you have to change existing code that you should also add semicolons as part of that update. Make that part of your ongoing process when you update code and it will minimize the effort when it becomes mandatory.
My point is, I have an awful lot of code that I will, in all likelihood, never touch as part of any ongoing process. I have report scripts that haven't changed in years - heck, there is code that hasn't been touched since before I started, because there's never been a need to touch it.
Which means that at some point, before these things become mandatory, I am going to have to update hundreds and hundreds of scripts that I would otherwise never touch. Sure, it's going to be spread over a couple of years at least - but there's gonna be a lot of it.
For example, we run a Microsoft CRM system that is heavily customized. Even assuming that MS does a bang-up job of reformatting all of the SQL that comes out of the box with CRM, we have literally hundreds of views, stored procedures, and functions that we've written ourselves; and those obviously won't be updated by MS.
The same is true for our Great Plains databases (we have several) and various other systems, both third party and developed in-house. We have mountains of code that simply doesn't change very often.
So yes, I get what Gail is saying and I don't disagree... I'm already making it a part of our ongoing process. But in our case, even minimized as Gail is suggesting leaves a massive amount of work to do.
And I get it - it's part of the job. We'll make it happen. But some automated help would be nice
Viewing 15 posts - 16 through 30 (of 35 total)
You must be logged in to reply to this topic. Login to reply