>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.

I think it's your last sentence that scares me a bit. Is just doing a cascading update so easy? With live data in SQL Server? If I use surrogate keys, I don't have to worry about it.

>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.

Don't I have to handle things differently if I don't use surrogate keys? In other words, when I do a cascading update in Oracle vs. SQL Server, do they each handle cascading updates the same way?

>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.