The pro would be that since the check is at the database level, you can ensure that there will never be any junk that gets into your database if non-SF applications touch it.  The con would be that you're not going to know about the constraint until you try to save the record, then it will throw an exception, so you'll also want to add a business rule to the business object to prevent saving when the field is blank.  We have the RequiredFields collection that can be edited through the class component designer just for this.  

Hello,

I'm working through updating our code to remove triggers and replace them with declarative R.I. rules.

I've also got a fair amount of trigger code that checks for empty field values (on not null fields), so I'm looking into check constraints as a replacement. But, I don't know if this is the right choice, or if the DDT supports check constraints other than default value constraints.

Here's a link describing how to set up a check constraint to prevent blank field values:

http://stackoverflow.com/questions/5489648/how-to-constraint-no-empty-strings-on-an-nvarchar-column

Can anyone chime in about pro's and con's of this approach, and where check constraints can be defined in the DDT for not allowing empty string field values?

Thanks.

Bill