|
 The Constraint
placement comboboxes allow to
choose where in the table definition various types of constraints
will be scripted. This setting primarily applies when scripting a
CREATE TABLE statement (when two tables are being synchronized, it
is:
|
·
|
Don't
generate - these constraints are
not included into the "create table" statement. You can generate
them later from the "Summary Collections" node of the schema tree,
or may be you just want to get rid of some of the constraints. For
FOREIGN KEYs this can help to avoid forward references to the
tables which aren't defined yet. |
|
·
|
With
column means that whenever a
constraint depends on a single column only, it will be scripted
with this column (e.g. "UserID int references
Users(UserID)").
Constraints depending on several columns will be scripted on the
table level. |
|
·
|
At
table level - the constraint will be
scripted inside the CREATE TABLE statement, after all columns. This
is not a valid setting for DEFAULT constraints, so the combo box
for them does not contain this option. |
|
·
|
Separate
- the
constraint will be scripted in a separate ALTER TABLE ... ADD
statement after the table definition. This setting can be specified
for any kind of constraint, although it usually only makes sense to
do so for the FOREIGN KEYs. |
Comparing
and scripting constraint names. On the server, all
constraints in a database have unique names. However, in many cases
the names are generated by the server itself and need not be known
in the SQL scripts (except when deleting the constraints). You can
choose whether such "automatic" constraint names should be taken
into accoutn when comparing and scripting the constraints. Checking
this option causes such constraints to be treated as
unnamed:
|
"Only
named", "Ignore names"
|
"Always"
|
|
create table
T2 (
ID Integer
Not
Null,
Name VarChar(30)
Not
Null,
Primary
Key(ID,NAME)
);
|
create
table T2
(
ID Integer
Not
Null,
Name VarChar(30)
Not
Null,
Constraint
PK_T2_014935CB
Primary
Key (ID,NAME)
);
|
Ignore
names tells the Diff to
consider two constraints identical if they have the same meaning
(e.g. the same value for a DEFAULT), even if the names are
explicitly specified and different.
Scripting
CLUSTERED/NONCLUSTERED
- both
PRIMARY KEYs and UNIQUE constraints are based on indexes, which can
be either clustered or not. For the PK, the index is by default
CLUSTERED, whereas a UNIQUE constraint is by default based on a
NONCLUSTERED index. Normally, the Diff would only script the
CLUSTERED/NONCLUSTERED keywords where they are really needed, but
with this setting you can force them scripted for each PK/UQ
constraint.
Scripting
WITH
NOCHECK - often there is no need
for the server to re-check the entire table when a constraint is
added (and especially when it is dropped and then re-created).
Adding constraints with NOCHECK option can make the scripts run
much faster on large databases. This option can be configured
separately for FOREIGN KEYs and for CHECK constraints. Three
scripting modes are supported for the WITH NOCHECK clause: (a) it
is not used (it's the default, as in previous versions); (b) only
script it when re-creating a temporarily dropped constraint; (c)
always script WITH NOCHECK. The "NOCHECK re-created constraints"
mode is supposed to be safer than scripting all constraints with
NOCHECK. However, both NOCHECK modes should be used only when
necessary and reverted back to the "checked" scripting
afterwards.
|
