Hi Craig,

>>Maybe it doesn't make any difference... Just a thought I had.
>

oh.. old topic again. You knew I was going to respond on this one, didn't you ?

>While VFP supports this, it violates defined rules for Primary and Candidate keys, which state that the value must be unique for the entire table. Just because VFP can "hide" deleted records is not a good reason to do this.

The rules you're referring to are the rules of the relational model. Since the differences between VFP and the relational model is quite large and the problem does not exists in the RM, we have to settle for a working solution. This is the only solution *IF* you want to solve this problem at the database level (rather than busines rules).

We can't hold on to the releational model forever. The official documents about the RM haven't changed much since the last 15 or so, while there were a lot of (R)DBMSs released since that time. Saying that we break the Primary and Candidate rules is like saying that we cannot work on sunday because god says so.... I does not make sense. If you know the RM well, you would know that *IF* we regarded the deleted records as tuples we could not have any working RI mechanism in VFP. In fact, VFPs RI builder also breaks this rule. *IF* the VFP team is allowed to break this rule, why shouldn't we ?!?

In my discussion with Jimb, Jim made a statement: "So the RI builder sucks, what else is new ?". I replied that all working RI meachanisms have this limitation and surely his own purposal for a new one. I never got a reply on that one. The problem lies in that DELETED records still exists. I don't regard deleted records as tuples, Both You and Jim do, and brings you into troubles to follow the remaining part of the RM.

If you really think that your statement is valid, please come up with some examples, solutions or some other kind of prove to backup this statement...

Regards,

Walter,