Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
ALTER TABLE [dbo].[REMINDER_EMAIL]  WITH CHECK ADD  CONSTRAINT 
  [FK__REMINDER_EMAIL__FACILITY_ID] FOREIGN KEY ( [FACILITY_ID] )
  REFERENCES [dbo].[FACILITY] ( [FACILITY_ID] )

ALTER TABLE [dbo].[REMINDER_EMAIL] CHECK CONSTRAINT [FK__REMINDER_EMAIL__FACILITY_ID]
share|improve this question

With foreign key and check constraints, specifying CHECK or NOCHECK enables or disables it. It's just explicit DDL that is generated by the GUI that, in your case, enables the foreign key constraint:

{ CHECK | NOCHECK } CONSTRAINT
Specifies that constraint_name is enabled or disabled. This option can only be used with FOREIGN KEY and CHECK constraints. When NOCHECK is specified, the constraint is disabled and future inserts or updates to the column are not validated against the constraint conditions. DEFAULT, PRIMARY KEY, and UNIQUE constraints cannot be disabled.

Reference: BOL ALTER TABLE

It is redundant and unnecessary, but I just take it as "verbose". If I was to defend it forcefully, I'd say it leaves the script reader without any question of functionality.

share|improve this answer
1  
The syntax does seem redundant. I thought for sure it would have already been reported as a bug on connect.microsoft.com/sql but it's not there. Based on the priority they place on other "correct, but not 100% correct" scripting bugs, it's unlikely such a report would ever be fixed. – Aaron Bertrand Sep 24 '12 at 17:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.