>My highly estimated Walter,
>
>>>My dear Walter,
>>Oh, now I have to be worried ;-).
>
> better this way? 8-)

It still sounds, ive got to be worried.

>You are trying to turn down my argument saying the same I said, but falsing the argument. You HAVE to rewrite some parts where you actually are letting the user enter the alternate (intelligent) key, but you DON'T have to rewrite all the child handling, and in a slightly complex system, this can be a daunting task, that you are underestimating. More over, as a key gets more complex, you have to make sure in your code that the added fields that get into are consistently completed.

I'm not trying to turn down the argument, but to analyze what the consequences are. The difference (more work in the intelligent key area) probably lies only in handling the data when ever the PK is used. My standpoint in this is that this in 'general' will be a much smaller problem than handling the UI. So what i'm implying is, that the problem with surrogate keys will probably somewhat smaller than handling intelligent key, but the main problem is handling all cases where the choice between surrogate or intelligent does not matter.

>>The only difference is that the retrieval and writing of those childrecords have to be modified. If having a flexible routine that does this for you, You'll not have much nightmare from that either.
>
>I can't imagine what's a "flexible routine" to you, Walter, as you seem to adore inconsistency, I'm afraid just of imagining it.

>As I said, you're not reading. 8-)

Then tell me what I should to read ?

Walter,