Hello
We often use Redgate SQL Compare for deploying schema changes between environments (dev → staging → production). However, we’ve noticed that default constraints (especially those with system-generated names like DF__Table__Column__GUID) often show up as differences, even if the underlying logic hasn’t changed.
This creates noise in the comparison report and sometimes results in unnecessary script changes or potential deployment risks.
We want to know:
- Is there a way to ignore system-named default constraints in SQL Compare?
- Can SQL Compare match constraints logically, not by name?
- Are there best practices for naming constraints to avoid this issue entirely?
- Will using the
/ignoretabledatacomparisonkeys or /ignoreconstraints switches in the command-line tools help in this scenario.
Hello
We often use Redgate SQL Compare for deploying schema changes between environments (dev → staging → production). However, we’ve noticed that default constraints (especially those with system-generated names like
DF__Table__Column__GUID) often show up as differences, even if the underlying logic hasn’t changed.This creates noise in the comparison report and sometimes results in unnecessary script changes or potential deployment risks.
We want to know:
/ignoretabledatacomparisonkeysor/ignoreconstraintsswitches in the command-line tools help in this scenario.