>So if you want to update one single key, you have to have some form of uniqueness in the child table wich are generally all the fields in the tuple.

So be it. Any comments regarding how efficient VFP is at this? Specifically, how much VFP can optimize the Update command when some of the WHERE clauses have non-key references, but at least one WHERE clause does include a non-unique key (the SSN, in my example).

This issue raises an interesting question regarding strategies for establishing unique, dynamic keys in databases. For example, the child table to which I referred can have any number of records with the same SSN. One way to generate a unique key for the child table is to simply use RECNO(). "But wait!", one might say. "Whenever you clean up and PACK that table, the value of RECNO() will change!".

I say, "So who cares?" The value of Recno() is only used for a few moments... that is, only when a user is accessing a set of records in a view with the same SSN. Recno() does not need to function as a static, perpetual key, but only as a dynamic, short-term unique key. When it's time for DBF maintenance, all other users will be locked out of the base (child) table anyway. So you can PACK the base table, then Replace All Unique_ID_Field with Recno(), and everything will be fine when users start running the app again becaue any views of the base table will also, unavoidably, retrieve the updated Recnos.