Here is a citation from the MSDN which contradicts yours. See the document called "Defining Business Rules for Data Access" in "Using Visual Studio"

"One of the most common uses for business rules is handling the referential integrity processes for indexed files. Because indexed files (such as VSAM) are typically just raw data storage engines, your application must provide custom code to handle constraints, foreign key deletions, and other common referential integrity issues. Application-based referential integrity can also be appropriate for relational databases, especially in situations where the available triggers, constraints, and stored procedures are either inadequate or too complicated."

>OK...since you asked..
>
>In the Wrox book VB5 Business Objects, from Wrox Press, ....on page 67 it states the following"
>
>The final area we need to discuss is the data services tier. At a minimum, this tier is responsible for creating, updating, retrieving, and deleting data from a data source. In many cases, it also includes more complex features, such as enforcement of referential integrity and other data-related rules.
>
>
>I am not sure this proves. It is all a matter of interpretation. Lhotka goes onto to say:
>
>
>In most cases, the data handling will actually take place on the database server. This allows us to put quite a bit of processing on the database server, using SQL-Server stored procedures and triggers. This can often provide important performance benefits, since most SQL database servers can opimise stored procedures so they run efficiently.
>
>It's important to note, however, that much of the work that a database server might have done in application may actually be more appropriately placed in our data-centric business objects rather than our SQL code. SQL is notoriously difficult to work with. It does not compare to tools such as Visual Basic for features such as debugging and flexibility. While it's still very hard to do some SQL coding in an application, it is opten much more cost effective to move the processing to a different layer in the application - where we can bring more powerful development tools to bear on the problem."
>
>My interpretation, which I happen to think is the right one since I sat one day and had lunch with Rocky Lhotka at TechEd in 1998 and asked him...<bg>, is that
>there is a distinction between the raw database server, and the data services tier.
>
>The data services tier, most of the time, is a COM component that brokers the SP calls and so forth to the database server. As far as RI is concerned, you have two basic choices. 1, you can place it in the data services tier, because it is engaged in low-level data operations and RI is inseparable from that, you can make it an intrinsic part of the database server through foreign key constraints and triggers. I personally have an affinity for FK constraints - without the use of triggers coupled with the use of a data-services tier that brokers this.
>
>When Lhotka talks about moving RI to a different application layer, he is talking about moving it from the raw DB server, to a data-services tier, not the business services tier.
>
>So there you go, you have a reference to some text that backs-up my point of view.
>
>
>
>
>
>
>
>
>
>
>
>>Thanks John. If you can reference any works, please post them.
>>
>>>Well lets see......
>>>
>>>Specific cites...I am sure I can come up with a few, but I wont at this juncture... Rather, lets use some common sense...shall we....
>>>
>>>The data services tier is concerned with two basic operations:
>>>
>>>1. Fetching Data
>>>2. Updating data - which includes inserts, updates, and deletes
>>>
>>>Now, if one believes that RI is inextricably bound to the act of updating a database, it is clear that the RI rules belong in the data services tier.
>>>
>>>Rules like - not selling to folks that have A/R over 120 days, or you cannot book an order for a customer on credit hold all belong in the business services layer. Rules like this can change over time. The rules can become more stringent, or they can be relaxed. These are classic middle tier rules
>>>
>>>A rule such as not booking an order for a non-existent customer belongs in the data services tier. Prior to letting updates go through, you need to know if an orphaned record will result, etc. These type of rules belong in the data services tier....
>>>
>>>However....
>>>
>>>I have only stated where the rules belong. There is nothing that says the business tier could not query the data services tier to determine if an R/I rule will fail. The two are contractually obligated to one another. More specifically, the business tier is contractually obligated to do whatever the data-services tier tells it do. If the data services tier says an update should not occur, the updates should not occur, regardless of what the status of the business rules.
>>>
>>>My argument is somewhat baited here... Notice that I said where the rules belong, not necessarily who should invoke the rules... In other words, I see nothing wrong with the biz tier invoking the RI rules hosted in the data services tier. In any case, the RI rules *belong* in the data services tier.