Thank you, James. This is what I was doing and I thought I could improve my application (read, reduce maintenance) if I delegate stuff/code to the SQL Server. But it turns out that it is not to be.


>Dmitry,
>
>It seems to me that you are doing an awful lot of work just to keep from using nulls. Use RI in your database then in your CAs check the columns that need to be null and and set the empty values to null before you save the row. JMHO.
>
>
>>Let me give you an example. User creates a purchase order. One of the fields of the purchase order is a cost center (an account) to which P.O. could be optionally charged. Each cost center is a unique field in the Cost Center table. The P.O. table has Cost Center foreign key. This Cost Center is a char field. If user enters a Cost Center in the P.O., everything is well. But when user clears (removes) entry from the P.O. table (because he/she decide that they do not want to charge the P.O. to a cost center), I want the Cost Center in the P.O. table to be empty string (not NULL).
>>Also when user deletes a Cost Center from the Cost Center table, after a warning, the foreign key in all P.O.s where the deleted Cost Center was used should be either set to NULL or empty string. I need/prefer that it is set to empty string. This is why I needed to have record in the Cost Center table with empty value in the Cost Center field.
>>
>>Does it all make sense?