Erik,

>> One question though. If you look at your projects, do you have a surrogate key for all (I said all tables intermediate results and cursor results included) ? I'll bet you don't. Then ask yourself why didn't you apply a surrogate key in this table. You may find one of the reasons i've mentioned before.

>The only tables that do not have surrogate keys are those that don't get updated by the user, and that are not involved in any relations. IE, lookups. As soon as the need arises to do either of these things, the table gets a surrogate PK. In _all_ cases.

From this I draw the conclusion that you don't either support the Forced use of surrogate keys. You've clearly drawed the borderlines where you don't want to use them (because they're not neccesary, just like a table containing hollydays ; the PK is a date). You've showed that at least you've though about this. The small difference between your and my standpoint is that I do allow intelligent keys in relationships. And when they change, just do a cascading update.

>>>>Hmmm, maybe you should add "and Joe Celko disagrees".
>>>Is he a VFP programmer?
>
>>Does this matter ? Does the whole surrogate key issue restrict to VFP ? I think not.

>No, but the questions on this forum do. Isn't that what this discussion is about?

Again I don't think so. The questions here often also apply to other (R)DBMSs like SQL-server and Oracle. Besides, I believe that most practices regarding handling data is transparent trough all (R)DBMSs. It should not make much of a difference, if you're using VFP, SQL-server, JET, Oracle, etc when we are are talking about SQL.

>>>Is it written in VFP?
>>Again, I don't see the relevance in whether or not this is written in VFP. the general principles stay the same.

>People don't generally come to a VFP forum to ask questions about general principles, they come to ask questions about how to solve a problem in their VFP application. Again, I don't see it necessary to end each of my posts with "But only in the VFP Universe", because we can generally assume that in the VFP forum, the topic is VFP.

See above. People tend to use more and more different datasource. The border between VFP and other datasources tend to get fuzzy.

Comming to the VFP topic. Did you never wonder how we could get rid of the status of deleted records ? This issue IMO is far more important that debating about advantages and disadvantages of intelligent and surrogate keys. I've submitted a wish that it should be possible that when a record is deleted, all xBase commands are scoped to non-deleted records only (even an INDEX command, and regardless of the SET DELETE setting). IOW when a record is deleted, it's gone (permanently hidden until a pack, or changing a table property). When this is implemented there is no difference between VFP and other (R)DBMSs when it comes to violation of uniqueness of PKs.

Walter,

Walter,