Greg,
I agree that your table structure needs work and that you should get that right before you start with forms and reports. However, I don't think its quite as bad as portrayed.
Your CustomersT table is Ok However, I would rename it to as PeopleT. i would then modify it like so:
PersonID (PK Autonumber)
Firstname
Lastname
Address
City
State
Zip
HomePhone
CellPhone
Email
MailingList
PersonTypeID (FK)
Notice no spaces in field names. Also since Access can include a line feed in text fields, I see no need for more than one Address field. I would than add
FamilyMembersT
FamilyMemberID (PK Autonumber)
PersonID (FK)
Firstname
Lastname
RelationshipID (FK)
You would also need lookup tables for the PersonType (Adoptor, Donor, etc.)
Next I would rename DogsT to PetsT in case you expand to different types of animals. so it would become:
PetID (PK Autonumber)
Petname
DOB
Living (??? what's this for)
MicrochipID (wouldn't this be a foreign key to a Chip table with details about the chip?)
Origin
Then I would add 2 more tables:
BreedTL
BreedID (PK autonumber)
Breed
and
PetBreedTJ
PetBreedID (PK Autonumber)
PetID (FK)
BreedID (FK)
the first is a lookup table of breeds, the second is a junction table to manage the many to many relationship between pets and breeds. Notice I took the adoption info out of that table since it should be in a separate table, Your AdoptionsT table is your
worst table since it has so much redundant info.
AdoptionT
AdoptionID (PK autonumber)
PetID (FK)
PersonID (FK)
NewName
AdoptionDate
AdoptionFee
ReturnDate
Then your BashDonorsT becomes:
DonorID (PK Autonumber)
PersonID
Gift
GiftAmount
GiftDate
That's all you need there.
The ChipClinicT also needs extensive trimming because it looks like there is a lot of redunancy. You should only need PetID as foreign key. You don't need anything about the Person, since you can get there from the Adoption table.
I suggest you make thise adjustment then we can help with the searching.