CathyZ said:
however, now they get a monthly current
list of farmers and want to link these two tables to deal with only the
monthly current farmers, and I want them to be able to select whatever month
they are dealing with and get it linked to the master list.
All you can do is cross your fingers that it'll be done correctly if you give
the users a tool that alters the structure of the database. You have a few
alternatives.
If you need to keep a history of these monthly farmers, then the users can
append each new list monthly into the same (permanent child) table, but add
two columns, one for the current month and one for the current year. If you
don't need to keep a history, when it comes time to import the current list,
delete the records from last month and compact the database, then import the
new list. You wouldn't need a current month and year, because it would be
understood that if there's a record in the child table, it's current.
Put a foreign key constraint on the permanent child and parent (master)
tables and the users will never have to use the wizard-like features you're
building into the application now. They would just need to import the
current list (and possibly delete old records and compact the DB).