I think a real obstacle for you will be that you're using FMP 10. Most people on these forums (including myself) will likely be using version 12 or 13, which can't save files (as far as I can tell) in anything less than .fmp12 format.
Your project sounds interesting but it's too much work for me to give you detailed instructions, but here are some tips. I recommend checking online help articles and tutorials on YouTube that will help you to understand various features (I use this all the time to remind myself how certain things work):
You'll want to make good use of the "relationships" tab in the Define>Database menu, and don't forget to click the equals sign on the line between the tables to set the ability to create and delete records via the relationship. This will allow you, in a layout which uses the Contacts table, to show data from the other table(s).
You may want to consider for your Memberships table that each entry represents a contact's membership for a particular year. So they have one entry for their 2015 membership, one entry for their 2016 membership, etc. This would allow you to keep a running record of when they paid, when their renewal was processed, etc.
I'd suggest your household be the primary table, and have contacts as a secondary table to it. For example, when you are entering a new member, first you enter their household information (address, etc.), then you populate the entries that indicate who are the people in that household. Trying to do it the other way (entering contact info for individuals then trying to match up who is in the same household) will probably be really complicated.
Thank you for your response. Unfortunately, I think this might be a bit over my head. I'll try another attempt at this -- and use all your advice -- but I'm still holding out for another quicker solution (hiring someone or purchasing an existing database). In the meantime, I'll need to try again to do this on my own. Let me start with this basic question: How do I make Households the primary table?
Start the input process with the Household Table. Using portals to the other tables (as one method) add info to the other tables.
Got it. I thought RG was talking about an internal setting, but now I understand it's about how I input data.
On to the next question: I've set up the basic Household and Contacts tables. I start by creating a new record in Households, then in Contacts, I type in the address, and it looks up the details in Households. I think we're good here. So what I want to do next is to have some of these contacts as members. The idea is to have a button in the Contacts database ("Add as Member") that when I click this, it runs a script in which it first creates a new record in the Members table, then copies the information from the Contacts table, and lastly assigns a unique membership number. I guess my question is: does this outline make sense? Am I missing something key? AmI really copying information from Contacts (which copied some information from Households)?
Thanks for your help! - Tom
The Member Table does not have to have the same information as what is already in another Table. Through the relationship you would use the necessary fields from Contacts when you need them in Members. Members would hold fields that are specific for the Member aspect and unique to it.
Okay, I think I'm getting it. Thanks for your help!!
Things seem to be progressing nicely. My "Add a Member" script seems to be working. Before I begin filling in more details, I'd like to see if I have the basic relationships set up okay. Any thoughts on this?