>>
>>I will have to formulate better of what I am trying to do. Thank you.
>
>I have to say, even though I like triggers - what you've described is one of the more unusual instances I've ever heard for triggers across many tables.
>
>If you had little control over the application layer (that posts the inserts/updates), then I'd say you probably don't have much choice.
>
>But if you have control over the original insert/update statements, that would (IMO) be the area of focus.
>
>My 2 cents.
First, thank you for your input. I do have control over the original insert/update but the reasons I am looking at triggers are the following:
1. Not all customers will need these "nulls" in the FK fields. So customizing the app for a one or a group of customers is PITA.
2. Making changes in 3-4 applications takes more time than creating the triggers
3. By delegating the job of making sure that the fields are not empty but NULL to the SQL Server is relatively straight forward.
4. I trust SQL Server to do the job more than I trust my code (where I could introduce a bug).
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
