>>>Thank you for moving it here!!
>>
>>LOL :) Seems that nobody cares :) We're only two who participating...
>
>I'll participate... now, what were we talking about? < g >

I believe, you just said, that:
>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.

What do you define as a a static, intelligent PK?

In SQL Server 7.0, I have to use triggers to cascade the updates and delete when using declaritive referential integrity. I have not worked with Oracle, but apparently it does not require triggers to do this.

And generally, I don't delete data. I will mark it as inactive.

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

I think this is incorrect, as noted about. Oracle and SQL Server handle the cascades differently, from my understanding.
==========================
Let's see, what Walter thinks about it...