CREATE TABLE dbo.foo
(
bar INT NOT NULL DEFAULT 0
, far VARCHAR(100) NOT NULL
, zar DATE PRIMARY KEY (bar, far)
)
comma separator is missing before PRIMARY KEY constraint declaration. And ScriptDom parses it as a column-level constraint linked to zar column which is wrong. Note, in such case column-level constraint has columns property with different columns listed. It should be parsed as table level constraint.
The syntax brings some ambiguity however it is completely valid. For created table sp_help shows no constraint for column zar and shows table-level unnamed PRIMARY KEY constraint on bar and far columns:
While developing rules for our custom T-SQL linter with columns declared as inline primary key involved, I have to double check if the inline PK is actually related to analyzed column. It would be great if such table-level constraints were parsed exactly as table-level constraints, not column-level.
ScriptDom version: 161.8919.0
Compatibility level used for parsing: 150
In this code sample:
comma separator is missing before PRIMARY KEY constraint declaration. And ScriptDom parses it as a column-level constraint linked to
zar
column which is wrong. Note, in such case column-level constraint has columns property with different columns listed. It should be parsed as table level constraint.The syntax brings some ambiguity however it is completely valid. For created table![image](https://github.com/microsoft/SqlScriptDOM/assets/13050317/e46f1c41-ba22-45b7-8d12-e898b4b245ab)
sp_help
shows no constraint for columnzar
and shows table-level unnamed PRIMARY KEY constraint onbar
andfar
columns:While developing rules for our custom T-SQL linter with columns declared as inline primary key involved, I have to double check if the inline PK is actually related to analyzed column. It would be great if such table-level constraints were parsed exactly as table-level constraints, not column-level.
ScriptDom version: 161.8919.0 Compatibility level used for parsing: 150