Predicate or key word all in uppercase?

Hi,

What is the dowside of not using all uppercase for predicates and key words?

I cannot find to see a problem beside adhering to a clean coding convention. After all I already have color coding so what would be the uppercase for?

Same question for the semicolon ; at the end of a sql block. Is that real necessary not to get in trouble sometime down the road or is it a non-issue. I find like I am now a C# guys if I use these ;

Just curious, I find tedious to switch from all upper case to normal case all the time. And not forget to type the ;

Thanks,

Philippe

Case doesn't matter for keywords. It is good to establish some consistent coding style in your organization though so it is easier to read the code. As for semi-colons, it will be good to use it in new code. There are also some new constructs that require use of semi-colon in previous statement to resolve ambiguities. And in a future version of SQL Server, we may require the use of semi-colons as statement separators.|||Thank you, got it.
About GO should I have "Some query" ; GO
or is Go Gone :-)
I never saw any advantage in using GO
it looks like it is implicit.
I suspect the answer is along the same line.|||GO is not a TSQL or SQL command. It is just a batch separator token for the client. You can configure it to be something else also if you want (like / or $$ etc).|||

Umachandar Jayachandran - MS wrote:

In a future version of SQL Server, we may require the use of semi-colons as statement separators .

Well, this seems frightening, I can't think of how many organizations would be in the impossibility to upgrade to such version without going through a major review of scores of existing (distributed) code. that seems very unlikely to happen. Lot of bugs ahead with that one.
I fully agree for brand new constructs but the day you can flip the switch to make this mandatory for every constructs seems very far away.
If it is 5 years from now, I am better off starting immediately in each piece of code I ever touch.
If it is 10 years from now, I can just start doing it for every new piece of code I create.
The legacy stuff should have vanished by then. At least for my application which has a somewhat short life cycle.
Philippe|||Our deprecation policy is fairly strict right now in the sense that we make announcement first in version N, then warning in version N + 1 and then deprecate in version N + 2. So you will have really multiple releases to transition and convert your code. Please take a look at the deprecation topics in say SQL Server 2000 and SQL Server 2005 for some examples on features that we announced for deprecation or removed and so on. Backward compatibility is a huge deal due to the installed application base for SQL Server and every release we go to great lengths to maintain that. The backward compat setting for databases are also a step towards that which allows you to run most code from previous version without changes. There are exceptions but those are considered breaking changes that you will have to fix in your application after/before upgrading. Lastly if you look at most of the examples in SQL Server 2005 Books Online or modules in Adventureworks db, you can see that the code uses statement terminators to suggest good coding practice.