Ok, I'm going to contradict myself here. Ideally, it would be handled via the database itself. However, if that is the case, then it will have to be handled in every backend if the app is moved or used with another backend. Is that the case? Or is this inhouse data where you will always control the backend? Also, even if inhouse data and an app you distribute or sell, if you are using Oracle today and switch to SQL Server next year, what then? Who will be responsible for the database and all of the data rules moving to the new backend? Is that acceptable? Sometimes adhering to standards is more important than anything else. What do the dba guys say? Do they want to manage it?


>>While preferably this would be done in the data tier, we do it in the business tier because our app can have multiple backends. By having it handled via code at the business level the backend is not germain. It suits our purposes fine.
>>
>>Of course you could create a separate 'logical' data tier in code to handle this type of thing. You could create your own data objects and place your appropriate code there depending on the backend type. Probably some would do that. It adds another level to maintain though but would work as well.
>>
>Tracy,
>
>Thanks a lot for your input. So far I have 3 votes for doing it in Business logic against 0 votes for doing it in database itself.