Hi Andrus.

>I have a number of such tables. So, since a local view is
>only reasonable way to edit child records, I must add surrogate
>fields to each of such table and re-write a large part of code ???
>I estimate this requires 800 hrs work.
>

All table should have primary keys. There is no foolproof way out of that. Now it's possible to use a combination of existing columns as your primary provided that you can guarantee uniqueness.

>>If the primary key for invoice child rows is a throwaway, in that you are only going to use it as a means to update the back-end data, the quickest and easiest way to do this is to define a column called PK C(10) in the base child table and fill it with SYS(2015) on Insert.
>
>I need to merge invoice rows created in different standalone
>computers. Using your recommended sys(2015), there may be
>duplicate keys if reading some other computer invoice rows.
>

>How I can resolve such problem?
>
>Also, I have 30 computers in lan inserting rows simultaneously.
>Are you sure that sys(2015) concurrent execution in each
>computer will not produce duplicates?
>


SYS(2015) duplications are possible but unlikely. I haven't run into any problems but I know it's, in theory, possible. Again, I point to Ed's suggestion as an alternative -or- you might want to look at Rick Strahl's sample code, available at his WestWind website, that generates GUIDs which are guaranteed unique (just a bit cimbersome).