Hi Chris,

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

In what way are cascading deletes more troublesome and dangerous than cascading deletes. O.k. we might get rid of the cascading updates with static PKs (note that they still can be intelligent), but we don't get rid of cascading deletes.

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

You'll have to setup your database right (and replication), which you should anyway. When done, there is not much different than handling surrogate keys.

Walter,