> In the bool, sp_bindrule states that CHECK constaints are preferred over
> rules though when limiting data. My question would be why? Yes, you can
> have multiple check constraints on a field, but it seems to me that check
> constraints are harder to manange. Thoughts?

> With user defined datatypes (UDT) you can attach rules which limit the
> data
> that can be inserted into the field that is tied to the UDT. The problem
> with using UDT's with replication is that if you need to change the type
> due
> to a rule change it causes a lot of pain. Say for example you have a UDT
> called udt_type1 which is defined to be a smallint which limits the values
> with a rule to be between 1 and 10. This UDT is tied to two fields in two
> tables. I now want to change one of the fields to use a new UDT called
> udt_type2 which is also defined to be a smallint but limits the values to
> be
> beteen 5 and 15. This will cause pain in that either the table needs to
> be
> removed from replication to be changed, or a temp field needs to be added
> to
> move the data into while I delete and readd the field with the new UDF.
>
> What I plan to do is remove the UDT and just bind the rule to the field
> using the base SQL datatype. This will allow me to easily automate the
> updation of a rule. I could use a check constraint, but this does not
> allow
> me to write a script to identify which check constraints need to change.
> I
> would have to custom code the update to include the specific fields in
> each
> table that would need to have the check constraint changed.
>
> In the bool, sp_bindrule states that CHECK constaints are preferred over
> rules though when limiting data. My question would be why? Yes, you can
> have multiple check constraints on a field, but it seems to me that check
> constraints are harder to manange. Thoughts?
>
> Thanks,
> Stephen