>An intelligent key that can not be changed whenever it is entered or when it has child records attached to it.

Can you give some examples of this? In examples given earlier by others, there always seems to be the possibility that an intelligent key is either incorrect (bad information) or entered incorrectly (data-entry error). Now what do I do?

>That's not what I meant. Each self-respecting (R)DBMS supports cascading, Restricts, Ingore or nullifies RI rules. How they're implemented is irrelevant: As long as i'm sure that when a PK is changed the RI rules are respected. If both a ORACLE and SQL server implemented the RI rules, it makes no difference for an attached VFP application to which server it's connected.

No, but if I am building both the VFP front end and the multiple backends, one backend hands the cascades for me, while one doesn't. If I use surrogate keys, I don't have to worry about it.

>>And generally, I don't delete data. I will mark it as inactive.
>
>That's very personal and limited behaviour. The majority of applications do delete data.

Yet in your example above, you cannot change an intelligent key. It seems as though this is a contradiction, unless I am misunderstanding you.

>>>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.
>
>See answer above, when implemented right, the results are the same.