It is not clear what you mean by:
Some of the fields are indexed between the 2 lay-outs
Best guess is that each layout is based on a different table or at least a different Tutorial: What are Table Occurrences? and that you have some kind of relationship linking the table occurrence on which one layout is based to the table occurrence on which the other layout is based.
Is that what you have? What is that relationship?
Don't know how to answer that. The fields I am wanting to edit in Lay-out 1 "read" automatically from Lay-out 2. And I want them to continue doing that. But I also want to be able to insert data into those fields in Lay-out 1 that are not connected to Lay-out 2. I am attaching a JPG of the relationships chart.
I think using the word "indexed" in my previous post was incorrect.
You are also referring to "layouts" when you really mean tables. Data is stored in tables and you can create any number of layouts based on the same table.
But I don't see just two tables in your relationships map. I see 8 Tutorial: What are Table Occurrences? "boxes" (one that does not have a data source table) that apparently refer to 5 data source tables.
Which represent the "two layouts" of your question? (Open Layout Setup on each layout and check to see what is selected in "Show Records From".)
Generally speaking, if you have two groups of records that hold the same type of data or nearly the same type of data, such as your paid and unpaid members, you would keep both groups of records in the same table, but use the value of a field to "mark" the records that record data for your paid members. But that's a general statement based on very limited info.
You are also linking records by name--which almost always does not work well as a way to link records in a relationship, but that's a new issue.
Names are not unique. You can have two people with exactly the same first and last names.
Names change due to changes in marital status and for other reasons such as "I never liked the name I was given at birth..."
Names are prone to data entry errors such as entering the name John Smith only to later find that it's John Smythe.
If you link records by name and then later have to change the name recorded for someone, the name change breaks the connection between tables and thus you have to carefully update multiple records in order to change the names and still keep records linked. A mistake can make a hash out of your data. This can be avoided by linked records by a unique ID such as an auto-entered serial number or Get ( UUID ) text.
Got a bit bamboozled with your answer PhilModJunk!!
The fields I am referring to are in the IMA lay-out & are "Gift Aid?" & "Gift Aid Form Rec'd?" - these are enterable when in the IMA lay-out but are viewable only in the IFF lay-out. But not all listings in IFF lay-out are also listed in IMA lay-out, ie not every one is a member of the IMA (a professional body). BUT some people who are not members of the IMA (ie listed in the IMA lay-out), have still sent in Gift Aid forms & I would like that to be recorded in the IFF lay-out. Currently these 2 fields in IFF lay-out say "Display Data from: IMA::Gift Aid? or IMA::Gift Aid Form?"
Which doesn't change the fact that you have significant design issues with your database.
I still do not know if your IFF layout refers to IFF or IFF 2 --- both appear to be two occurrences of the same table. But when you add fields from a related table occurrence (IMA::Gift Aid), it can make a very big difference.
But the key info is in your last post. You have people who do not have a record in IMA for home you want to enter data into a field from the IMA table. This is not possible without first creating a record in IMA. This could be done simply by allowing "Allow creation of records via this relationship" for IMA in the correct relationship (Which might not exist if your layout is based on IFF 2.)
But that creates a record in IMA for them, making them, apparently, a member of an organization for which they are not a member.
This simply re-emphasizes that you need a different design structure for the tables in your database. It appears to me that you need a single table with all IFF and IMA records in it. If you have a record for the same person in both tables, such records should be merged into a single record. Membership in IMA can be handled either by a field that indicates that they are or are not an IMA member or you may want to set up a related table linked by an ID field were a new record is created each time a person joins or renews their member ship. That may be very similar to what you have now except the only information you would copy from IFF to IMA to record a membership would be the value of a single ID field.
Your Gift information--since it can be given by non-members, should be logged in yet another table so that you do not have to create a membership in order to log the receipt of a gift.
Thanks PhilModJunk - Your last sentence has given me the best solution - simply to create another table of all the Gift Aid people and then reference that back into either IMA or IFF (or both if that works!) - then I just have to go to the Gift Aid table to see if someone can Gift Aid, regardless of whether they are members of the IMA or not.
Appreciate the time you have taken with your answers - thank you!