tags:

views:

44

answers:

2

Note: This question is not related to Visual Paradigm. Anyone that knows SQL could answer it.


I am using Visual Paradigm to model a database in our project (using ER diagrams). When Visual Paradigm generates the SQL equivalent for the database and I import it in MSSQL it works pretty.

I took a look in generated SQL code to make sure anything is right and I saw something strange!:

For tblContracts I defined a constraint named EndAfterStart to make sure the value of endDate is always bigger than startDate. The generated SQL code for this constraint is here:

IF NOT EXISTS (SELECT * FROM sys.check_constraints WHERE object_id=OBJECT_ID(N'[dbo].[EndAfterStart]'))
ALTER TABLE [dbo].[tblContracts] WITH CHECK ADD CONSTRAINT [EndAfterStart] CHECK (([startDate]<=[endDate]))
GO
ALTER TABLE [dbo].[tblContracts] CHECK CONSTRAINT [EndAfterStart]
GO

And the questions:

  1. Why tblContracts is altered twice to add this constraint?!
  2. Isn't first two lines enough?
  3. What is different between second line and forth line?
+1  A: 

The second line adds the constraint to the table; the fourth line enables the constraint.

lmsasu
+2  A: 

First and second lines create EndAfterStart constraint if it doesn't exist. Fourth line enables EndAfterStart constraint.

Constantin
@Constantin - You are right. but when i omit the Fourth line, the created table also has the constraint enabled.It seems in generated SQL, constraints are are enabled explicitly, despite it is already enabled or not.
Isaac
I guess the script was designed to be suitable for creating constraints as well as for "getting database schema back in shape". For some reason authors preferred not to put 4th line in `else` clause.
Constantin