Hello Walter

Sorry to drag back such an old thread but I remembered what you had said about using intelligent keys, (filtered on DELETED()).

I never did write that update function I discussed during the thread and so I am now faced with the same situation as before.

I need to do an append into a table from another table and I would like to keep the PKs in the source and the target tables the same. This time I have the same PKs in both tables (if the PKs exist at all)

Of course if I do a straight append I will get an update conflict even if I have deleted the records in the target file.

Could you point me a discussion of intelligent keys or expand on the idea some more for me.
Did I see some threads that advised against using them or am I imagining it:)

Thanks

>Mark,
>
>Yes, You've got a problem here. Apparently this is one disadvantage of using surrogate keys, and you've got to find a workarround. Instead of deleting, you might try updateing the records.
>
>You would not have this problem if you were using intelligent keys, (filtered on DELETED()).
>
>Walter,
>
>
>
>>I have been using integer surrogate primary keys for a while now but sometimes I still wonder if I have the right idea.
>>
>>In the old days if I wanted to replace an entire set of parent records with a new set from a different source, all I had to do was delete them and append in the new set (with safeguards of course).
>>
>>Now I can no longer do this because my child tables still refer to the parents old primary key (my nextkey() routine having created new keys automatically)
>>
>>So nowadays to do the same job, I find I am having to write routines that update the existing set of records. This involves.
>>
>>Comparing old record set with new record set looking for deletions.
>>Comparing old record set with new record set looking for Additions.
>>Comparing old record set with new record set looking for changes to the records.
>>
>>and of couse wrting code to make any changes to the old record set that may be required.
>>
>>Of course of in a perfect world both my old set and my new set would both have the same primary key because they both derived from a single original source.
>>
>>At present this is not the case for the data environment I am in and I am getting fed up with coding for this situation.
>>
>>My questions are.
>>
>>1. Does it have to be this awkward or have I made some fundemental mistake in the way I am using surrogate keys.
>>
>>2. If so..... does anyone have a nice solid function that will do all the checking and updating I mention above:) I am sure I have written this before and lost it sometime ago.
>>
>>
>>Muchos danke mes ami