Hmmm, good point. I was thinking that if the constraint was already trusted, that the ALTER command would be skipped. But that's a lazy (and potentially time-consuming) assumption on my part. As I only did this once on a database, it wasn't really an issue for me (I did this when I was down for maintenance).

This arose for a decidedly non-random reason BTW: a 3rd party app was executing several stored procedures very slowly. Turns out there were hundreds of untrusted FK constraints that were created NOT FOR REPLICATION.

Unfortunately, it also turns out that you cannot, apparently, make a constraint trusted if it was created NOT FOR REPLICATION (I posted a while ago about this http://www.sqlservercentral.com/Forums/Topic944850-146-1.aspx). You have to DROP and CREATE the constraint.

While looking up info, I came across this post that suggests BOL may be inaccurate about this: http://connect.microsoft.com/SQLServer/feedback/details/585467/with-check-constraint-can-leave-table-with-untrusted-foriegn-keys.

Yours,

Rich