as Sql server create tabel syntex after last comma CONSTRAINTS are placed , in case there is no information provided to sql it assumes there no key define.

I have noticed this before as well. Checked the "BNF" in BOL and that one is certainly correct as in that it doesn't cater for a trailing comma. So please, enlighten us why this is silently ignored?

HI Madhivan,

Its quite interesting and sweet like you.can u please explain???

Thanks in advance.

Extra comma after last column is allowed because it makes code easier to maintain. The same approach we can see in programming languages. For example, in C# when you use object or collection initializers, you can also use extra comma:

List<int> digits = new List<int> { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, };

Olga,

You say 'it makes code easier ot maintain'. How is that? Area we talking about a single click of some sort or not having to press the backspace key?

All I know is that whenever I pivot vertical items into a horizontal list using xml path('') I always bend over backwards trying to remove that extra comma at the end. Maybe the people at Microsoft noticed that and decided to ignore all trailing commas as a principle. Ha ha!! :-)

dishy,

Under "easier to maintain" I meant that, for example, if you want to add/delete some value to array (in case of collection initializer) or some field/property of a class (object initializer) or some value to enum, you can just add/remove/comment out just one line. For example, you have enum WorkingDays and you want to remove Saturday from that list, you can just comment out (or remove) last line without removing comma from previous line:

public enum WorkingDays
{
           Monday,
           Tuesday,
           Wednesday,
           Thursday,
           Friday,
           //Saturday
}

And this behaviour for array-initializers goes from C# language specification: "Like Standard C++, C# allows a trailing comma at the end of an array-initializer. This syntax provides flexibility in adding or deleting members from such a list, and simplifies machine generation of such lists."

So I think that SQL Server has the same reasons to ignore trailing commas.

@Olga Medvedeva if it was that way, it should also allow for optional comma in SELECT list, where it would be extremely useful:

SELECT
  col1,
  col2,
  --col3
FROM source

or

SELECT
  --col1
  ,col2
  ,col3
FROM source

To me it's just a parser or spec bug. Take care :-)

It really helps maintaining code especially when design changes reorder the rows or you temporarily want to remove a row.

However, the benefit only comes in action when you use the syntax with one column per row, i.e.

create table a (
 firstrow varchar(50),
secondrow varchar(50),
timestamp datetime,
)

if you use a single line code, you will gain nothing, as commenting out parts of a code line is something you should not do on a regular basis. For me, thats perfect, especially in select clauses where I can comment in and out columns (e.g. those that are only relevant for the customer, but not for my tests).

To analyse a reason for such behaviour, I have tried to use native DOM parser and see how it be processed. I have realized, that comma is included into statement ColumnDefinition. I think comma is kind of split char separator (last empty element is ignored and it is absent after parsing). SELECT has different behaviour because it is SelectColumn statement and probably has different parsing logic.