Thanks, Mike.

>If you want, you can use Delcaritive Referential Integrity (DRI) to enforce restricts. Include a REFERENCES constraint in you table definition.
>

DRI is too strict for some situations. For instance, a table that can have nothing/blank for a foreign key as well as an actual valid foreign key causes problems (now I'm not sure if it is VFP or SQL where this happens).


>As you found out, SQL Server does not have any built in way to cascade deletes or updates. Which is good for me because I one of those people who believes that you shouldn't change primary keys.

I agree, changing primary keys is bad business. For our backend, we won't, but at the moment, our new offline child records need to have something relating them to their new offline parent before they get synched up to the SQL Server. I am about to bag the whole concept and choose a more disk space costly or net traffic costly solution.

>
>> I don't know how to cascade parent key changes to children when it is more than 1 parent record being changed.
>
>
>That's a good problem. There's nothing to link the Inserted and Deleted tables if you've changed the primary key. Is there a candidate key that can be used to relate the children?
>
>-Mike

That's where I am. I wanted a generic or at least template solution.
I started all this by trying to make the databases as similar as possible. At this point it is merely an exercise. The data behavior is similar enough so my app is happy.

Cheryl