>Nancy,

>RI is a data issue, the conditions and approaches to enforcing it are business in nature. Referential Integrity simply refers to protecting the integrity of the PK to FK references within the database. RI itself doesn't say anything about how to protect the references. Most databases will give you simple abilities for declaring RI rules, the standard cascade or restrict. However, most business situations are not that simple. There are situation where a rule would be cascade and others where it would be restrict and still others where it might be ignore.

>Part of this discussion is rooted in the idea of 3-tier architecture. Once one beraks from the 3-tier thinking the options expand considerably. If one considers a five tier architecture;

>User Interface Layer
>Input/Output Layer
>Business Layer
>Data Services (Access) Layer
>Database Layer

>Then it becomes more clear that the optimal location for RI rules is in the Data Services or Data Access layer.

I'm afraid I have to disagree with you, oJim! ;-)

I don't agree that what you discribe above is 5-tier architecture. It's 5-layer architecture which is substantially different from 5-tier architecture. The user interface layer and the i/o layer represent the front end in this case, and the database services layer together with the database layer really is the data tier. One can introduce lots of more layers without really creating new tiers.

And as I pointed out in my long (top-branch) message, there are logical reasons that come into play when moving to non-relational back ends which make it important that parts of the RI do not reside in the data tier.

There is an easy point to be made here: Try creating a VFP backend and access it through ADO and see what happens to your RI. >s< OK, this is an implementation detail and based on bad design/ missing features, but I think you see my point...

Markus