>>4) A surrogate PK is easy to keep unique as it carries no meaning and therefore can be forced unique by a program. Using surrogate PKs removes the need to test for uniqueness during data entry and the associated actions on the part of a user to determine a unique value.
>
>Here you are shifting the problem. If the table has another intelligent key (articleno) you'll still have to check for uniqueness, which IMO is best done with the help of a filtered candidate key.

No I am not "shifting" the problem. I am eliminating the problem from the Relational issues and moving it to the business issues. Business issues do not effect the integrity of the system, they may effect the accuracy of the system. If the systems integrity is intact then the accuracy can be fixed. I simply choose NOT to expose the system integrity components to human intervention thus making the insurance of systme integrity easier and more robust.

>My question is, what will you do when you're asked to develop a VFP application for an existing DBMS (let's say ORACLE) which uses intelligent keys for some tables which you want to download into a VFP database ?

Existing systems are outside of my direct control. I am responding to the issue of choosing one way over another. In an existing system I don't have that choice because the system already exists and has already been configured using one or the other system. I can ask you the same question, if you come across a system that uses surrogates exclusively will you change it to use natural keys in certain tables or work with it the way it is? The answer to this question is obvious to me, we work with an existing system as we find it unless we have been assigned the task of redsigning it.