Jim,

>I really don't want to go into this again. We have been through all of this before. This will be my last message in this thread.

I'm sorry to hear that. I still trying to figure out why your VFPs RM implementation is so different from mine and why it is leading to the same (in my eyes) weird and unthoughtfull answers to anyone asking for support regarding this topic. Therefore I'll not rest to answer and fight your phylosophy until you've proven why your approach should be followed in ALL circumstances. My concern is, If I don't understand why you do it this way, why should the poster understand ?? We should make the poster aware why this is the best solution, an not answer because I say so. This way we are getting nowhere and might be riding the dinosaur.

>>I have not spoken a word of the physical implementation. I don't care of how the table is physically written to disk. I'm merely comparing a relation and a VFP table. I really don't understand what you're trying to say here.

>When you discuss a VFP table you ARE discussing implementation and not relational theory. There is no way around that.

When we talk about the deleted records and its relation to the relational model there is no way around that. The point is how to handle the RM within VFP.

>The decision of using candidate indexes is a decision of implementation and not one of relational theory.

So the anwer to this question might be: "By using filtered candidate indexes" ?

>>rule 1: According to the RM you can only insert a foreign key if a corresponding primary key exists.
>
>This is NOT a relation rule. There is no riule that says a foreign key cannot be NULL, that is not pointing to an actual parent record.

There is only one condition where a foreign key without a parent can exists, and that is when it is .NULL. The fact that VFP allows us to leave it alone is not described by the RM. I'm not sure if a child record can be inserted with the value of .Null. or can only exist by deleting the parent.

>There is also no relational rule that says that a foreign key must point to a vlaid parent record. Those are business rules, that's why they are referred to as the "Key Business Rules" in all relational textbooks I have. The point being they are the "business rules" that describe the management of the "keys".

>As for how I solve the problem, I use a multitiered architecture where there objects that have specific mehtods for enforcing the business rules for the application. I solve each specific business rule problem within the business domain of that application by using the business objects and their methods. I don't ask the database to enforce anything but the field and record domains of the database, the key business rul;es are part of the business domain and they are handled as part of the business layer of the application. The database is not asked to enforce the uniqueness of anything but the PK.

We're stuck on the business rules again.... No, not all RI can be catagorized under business rules. Even in this case, Your business rules have to regard the deleted pks as non existing. There are many RI rules that are not business dependant. If we delete an order, we must delete the orderlines. We can only insert orderlines if a corresponding order exists. etc.. In fact most RI belongs to the database as well as certain businessrules.

The choiche whether to use the CASCADING, UPDATE or NULLIFIES methods of RI might be a businessrule, but should be implemented in the database (if possible), not in the business objects for the following reasons.

- There is usually no suitable way preventing direct (so not trough the business rules) access to the database.
- When doing maintenance which cannot be done trough the businesslayer, you'll have to access the database in a direct way (For example: give all female exmployees a raise of 10%). If there are businessrules that say that the maximum salary is a certain amount, the database will protect you for giving to much raise. You cannot write business rules for each thinkable DML action.
- Business rules used to force integrity tend to be buggy no matter how well defined. When using buffered tables in a multiuser environment there ussually is no way of securing the database. One bug might cause the whole ship to sink. Don't get me wrong, virtually none of all database is secured for 100%, but it would be nice if we can get as close as we can.

I think the problem might be that you confuse tiers with layers and choose a tier (implemented as object) to implement a layer. IMO a business layer can be physically implemented in three ways:

1. only in the database (with stored procedures)
2. In the database and in a second tier
3. only in busines object tier.

You seem to have choosen for number 3. IMO this is the worst choice. The best choice, how odd it may seem is number two. The part that has to secure the integrity of the database should be in the database, the part that describes the rest of the business on the business objects.


>Again, here you are discussing the implementation details of VFP in the context of the relational theory. These two subjects are not the same thing. The relation theory specifically says that the developer is insulated completely from the implementation details of the data storage and with VFP you are NOT.

Then why reffering to the RM when using Primary or candidate indexes filtered on DELETED() ?? Why ????


Bottom line is that the choice of securing the integrity of your database is one of personal prefferences, whether you choose to write code to enforce it or use the available features (database rules) to enforce them. I think we should never answer such message again in a way we leave the poster with the question why or "If the GURU says so, well it is so". Explain as throughely as we can. If he makes use of business objects, he might do it there, or else he might implement it on the database level (with the help of a filtered candidate index).

Walter,