Thank you John Vinson !

[Linda]

THANK YOU SO MUCH JOHN:
Because of your comments my Boss will allow me the time
to setup all tables correctly !!!!!

I do have a question about how the "City" is handled?

The specific one-relationship is: Vendor Contract Num +
Vendor Name + City; everything else can be multipules:
More than one Vendor Name per City.
More than one City per Vendor Name.
More than one Vendor Contract Num per Vendor Name
More than one Vendor Name per Vendor Contract Num

Also, how will I read the Fee Codes "Charged" to the
Vendor and then find the Fee associated with the Fee Code,
show each Code and Fee and than sum it all up?

Do I need an input form that they put in Fee Codes Charged?

Do I need a report or invoice report ?


THANKS SO MUCH FOR ALL YOUR HELP JOHN !!!!!!!!

-----Original Message-----


WHOA!!!! Stop RIGHT there.

"Fields are expensive, records are cheap". If you have up to ten Fee
Codes, someday you will have ELEVEN fee codes, and need to restructure
all your tables, and all your forms, and all your reports, and all
your queries. If you have a one to many relationship, *model it as a
one to many relationship*, not as redundant fields.


That's where you went wrong (one of the places). Instead of ANY of
these Fee fields, have a VendorFee table:

VendorID <Long Integer, link to the Autonumber>
FeeNum <Integer 1 to 124, or maybe to 125 or 131 tomorrow>
Fee <Currency>

VendorID and FeeNum would be a joint two-field Primary Key, and the
table would have up to 124 rows for each vendor.


Same logic. A single table with FeeNum (1 to 124) as its Primary Key,
and a single text field. Join it to the VendorFee table to link the
fee currency value to the fee code text.


and again - you have a Many to Many link from Vendor Contracts to Fee
Codes.


Well, they should certainly NOT be set up the wide-flat way you are
proposing!!


Good luck introducing your coworkers to the wonderful world of
normalized data structures!


.

..