>> Yes that's RI. RI preserves relationships between tables when records are
>> entered or deleted, it's not a business rule.
>
>That depends. For many parent/child relations, this is true, and therefore, the RI for this part needs to reside in the data tier. But for instance, there is no relationship that needs preserving between a certain location and it's weather data (i.e.). You say there can't be weather data if the location gets deleted? Well, why not? Is my database corrupt? I don't think so! Is it logically not valid? That's absolutely true! According to my real word knowledge of locations and their weather conditions, this would result in a logically invalid situation. And that's business logic. Therefore, this RI belongs to the business logic.
>
>Also, I want to point out that the fact we need RI in the data tier is a VFP specific detail to begin with (OK, it applies for all relational databases). The fact that we split entities in 1:n tables is based on the fact that we don't have a way to efficiently describe large amounts of data in their real world representation. That's a technical issue. Everything else is busines logic and belongs there.
>
>Markus

Markus,

This was my point when I started this thread ( a few days ago ).

For me data tier rules are the container rules ( abstract data ) who have nothing to do with the real data. ( contained data )

RI is a container rule

You are right, everything else ( the real side ) is busines logic.

Tks for the clarification

Just curious, you know a parent/child relations not "drawn by numbers" ?
Actually a computer is nothing more than a calculator.

Marcel