Formatting anomaly

In case the lines following the header are commented the same way the as header (that is, both using '--' or '/* ... */), formatting the code will remove the commented part, unintentionally resulting in code loss.

Formatting for (header):

	Code:
	-- $DATE$ $TIME$ Formatted to SQL Server default

editor contents:

	Code:
	-- SELECT -- s.[name] -- ,s.id -- ,s.xtype -- FROM -- dbo.syscolumns AS s SELECT s.[name] ,s.id ,s.xtype FROM dbo.syscolumns AS s

Result after formatting:

	Code:
	-- 2012.06.26. 16:24:36 Formatted to SQL Server default SELECT s.[name] ,s.id ,s.xtype FROM dbo.syscolumns AS s

Also, formatting removes language specific accents as well :(

The language specific issue is history but the code loss due to formatting is still present in 6.3.153.

This is still an open issue. There seem to be no reliable way to identify the old header and separate it from other comments in the beginning in case it changed in the settings. We are looking for a way to setup some sort of regular expression to separate the header part or alternatively create a new requirement to have at least 1 empty line separating the header

For tracking purposes here is the issue #SA0020608

Last edited by SysOp on Mon Nov 05, 2012 6:43 pm; edited 1 time in total

I see. Meanwhile I've experimented with it and came up with (bit lame) workaround. While it can happen that the comment types are combined, it's still unlikely. So I changed my (header) formatting to:

	Code:
	--/* $DATE$ $TIME$ etc. etc. */

Now formatting leaves comment intact as long as there are no combinations of comment types at the top of the script.

That should work, but the header doesn't look pretty. I hope we can develop a better solution not requiring jumping through the extra hoops to get the formatting to confuse headers and other comments

Well, yes, it's rather pretty ugly and does not protect from code loss every time. I plan to remove that when you find a solution for this issue. Until then it remains a scar in my scripts :(