Thanks for the reply. Your thinking mirrors my own point for point(although I hadn't considered the GTO), so I shouldn't look at any more replies in case someone disagrees!

>>2. Your boss (who is an ex-Clarion developer) will not be able to
>>sabotage your code and criticize you anymore.

Ouch, that sounds like the voice of first hand experience.

Thanks again.

Gary


>>Hi all,
>>I'm looking at the pro's and con's of the two approaches for handling RI.
>>
>>xCase gives me the option of generating either or both. I tend to favor constraints just for simplicity but I'm open to other ideas here.
>>
>>Of course the specific database design will affect the decision on where to use/mix these tools, but I'd like to hear some opinions in general. Thanks.
>>
>>Gary
>
>Some of the pros of using constraints for RI:
>1. Less code ('nuff said)
>2. Faster execution.
>3. Applications that use the database schema (MS-Access, Visio, Rational Rose, etc...) can use the RI constraints as the foundation of a data model.
>4. EM's Database Diagramming tool uses RI constraints to draw nice pictures of your database.
>5. Programming tools can use RI constraints to enforce the RI before touching the database, which conserves resources. A good example is .NET DataSets.
>
>The cons:
>1. Really old-school database developers will not be able to figure out why they cannot insert a new invoice record for a non-existent customer.
>2. Your boss (who is an ex-Clarion developer) will not be able to sabotage your code and criticize you anymore.
>3. You may find yourself trading in your '68 junker for a '05 GTO.
>
>There are good uses for triggers in conjunction with constraints. Constraints only deal with one row at a time. The only way to perform entity-level validation is by using a trigger. A good rule of thumb is to always use a constraint when there is a choice.