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
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.
column means that whenever a
constraint depends on a single column only, it will be scripted
with this column (e.g. "UserID int references
Constraints depending on several columns will be scripted on the
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.
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.
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
named", "Ignore names"
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.
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
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