All the advice you are getting is correct. Every table should have a meaningless, unique primary key value. Add a primary key value to the detail table. We have had many discussions here on the UT about whether the PK should be a combination of other columns or a system generated value. I prefer to use a system generated integer for stand alone systems and GUIDs for systems that aggregate data from other systems.

Also, I avoid the use of underscores (_) in table names and column names. They do not really make the names more readable and add extra keystrokes. Also, if using free tables, it allows fewer characters in the column name. So inv_no becomes either InvNo or invNo. inv_date becomes either InvDate or invDate.

>what's the right table structures for one-to-many forms?
>
>eg. for invoicing, I use:
>
>invoice.dbf
>---------------
>inv_no
>inv_date
>cust_id
>
>inv_detail.dbf
>------------------
>inv_no -> foreign key of invoice.inv_no
>stock_id
>qty
>price
>
>while my friend insists the right way is:
>
>invoice.dbf
>---------------
>inv_pk
>inv_no
>inv_date
>cust_id
>
>inv_detail.dbf
>------------------
>inv_fk -> foreign key of invoice.inv_pk
>stock_id
>qty
>price
>
>in his opinion, the key shoud be meaningless, not represent anything.
>
>while my way (using invoice number) will cause lots of problem in the future, espesially with SQL databases.
>
>please advise.
>
>regards,
>
>Jerry