Incidentally, I was unpleasantly surprised by the introduction of mandatory semicolons into what should be a nice clean syntax that can be parsed unambiguously without these markers. I wonder whether something has been added to the language that genuinely prevents detection of some statement boundaries without specific separators (that would be a pretty stupid thing to do, but I've seen stupider things happen) or was some parser development team just too lazy to do it right; and I'm sad to see that MS is planning to make unneeded separators mandatory at some point in the future.
As far as I know (and I'm too lazy to check right now), the semicolon has always been mandatory in ANSI SQL.
I'm glad it will become mandatory. One of my worst nightmares was when a coworker was repairing bad data in a production environment. To make sure he got the WHERE clause perfect to find only the rows to be removed, he used this code:
--DELETE FROM TheTable
SELECT FROM TheTable
WHERE (very complex clause)
When he finally had the WHERE clause perfect, he uncommented the DELETE, then hit the EXECUTE button.
This was the only time we were all glad that the triggers on this table were so painfully slow (they used row by row processing, in a very inefficient way to boot). After a few minutes, the phone started ringing because all users were blocked; we were able to kill the process before it finished. Which saved us a LOT of grief, since that database was in the simple recovery model.
With a mandatory semicolon statement seperator, this mistake would simply have returned an error message.
Also, while it may be possible to build a parser that does it job without needing semicolons, evenn Microsoft has limited resources - I'd rather see them spend those on new features rather than maintaining a parser that could be simplified by simply requiring semicolons.
Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis