You'll need to describe your database in more detail before we can help you.
I'm guessing that you have a single table for all your data. If so, one of the first tasks will be to create more tables. You could, for example, have one table that functions as a ledger for all your donations. A second table would list all donors and their contact information. You'd then link the two tables with a relationship so that when you view a record for a particular donation, you can also access the name and all other information on the Donor.
Here's one point new FMP developers often miss:
Don't link your tables by a person or company's name. These names are subject to change at any time. Jane Smith gets married to John Doe and changes her name to Jane Doe. Acme Construction reorganizes and now is known as Acme Building International... If you used names, this type of change, will "break" your relationships.
Instead, give each such record a unique ID number to use in relationships that link your tables. That way name changes don't cause this problem.
If you haven't done so already, you may need to pursue additional education on how to do this. There are books, tutorials and on line articles available that can help.
Thank you. Your information was very helpful. As you suggested with the donation ledger, would I then also be best to create a table for each of the programs and then link back to the contact lists? I am assuming it is not possible to go to one source (the contact) and be able to enter all of the various components for which they participate (ie: donation, programs, events).
You can do it either way.
It depends on what you need to store in your database and how you plan to use that information. Generally speaking, if one person can be a participant in many programs, you need a table for your programs (one record for each program) and another table that serves as the link between your table of people and your table of programs. This is called a "Join Table". As you can see, this can easily get pretty sophisticated for a beginner to tackle!
On the other hand, if you need to store only the names of the programs and there are a very small number of programs involved, you might get away with a separate field in your people table for each program. That approach is often easier for a novice to implement in terms of setting up some simple layouts for collecting basic information. This is a MUCH less flexible approach, however, as you have to add a new field each time your organization adds a new program and reporting can also get harder to do.
You're asking good questions and planning out a "paper design" of your database will often save lot's of grief down the road by avoiding the pitfall of trying to make a poor database design do what you need.