Layouts are based upon a table occurrence. So if you create a layout for table A and place fields from table A on it, that is what you will see. Notice that the records indicator shows the number of records also from table A.
If you want to view the records for table B, create a layout based upon table B and place table B fields upon it.
If you relate the two tables then you can 'cross view' fields, i.e. place table A fields on table B layout and view the information.
I cannot explain any more without specific example. If you wish to provide further information, please use real table names and not A and B. To provide logical answers, we need to understand what the underlying tables represent. So say "I have a Customers table and an Invoices table", for instance.
BTW, if you select a layout and then (in layout mode), select Layouts > Layout Setup, you will notice in the center of the opening dialog, 'Show Records from' and a pop-up list. Layouts are always tied to a specific table occurrence and that will become your perspective when viewing all other data (whether from that table occurrence or a related table).
Thanks. By the way, the method I used for creating two tables that had both had many of the exact same fields, was by building the database once, then 'saving a copy' as a differnt name. Is that problematic? (I can't seem to find a way of copy fields from one database to another; it seems like maybe I can in 11 pro ADVANCED.
Copying data from one table to another is redundant. The whole purpose of relational structures is so that information is entered once in only one place. If it is needed elsehere, a relationship is created and the data is displayed through the relationship. Otherwise, if you change the data in one table, the other table which held the same data will now be 'off.'
I still am unclear on exactly what you want to accomplish and what tables are involved. Can you give me an example where 'two tables had many of the exact same fields'? I can explain more how the information can be properly shared by only using their primary keys and allowing the data to exist in only one place.
Also, please drop the phrase database ... in FileMaker, you have tables and you have files (using 'database' confuses the perspective). One file can have several tables and one file can have several tables which can relate to each other AND these tables can relate to other tables in other files. You aren't using 'Save A Copy As' and copying the entire file are you? Either way (whether copying the file or copying tables), it probably isn't necessary. Each table should contain different fields which hold different information. For example, you should have a Customers table. If you have different types of Customers then you include a Type field to specify the different types of Customers. But all Customers should reside in the same table.
Explain more please. :^)
Sorry about the misuse of the term database. Will try to use Tables instead.
As to why, here is one example.
I have a client's table that includes address info for each client. Then, I'll have a 'checks received' table. Then, I'll have a 'checks disbursement' table. In the checks disbursement table, I'll want to pick up the the client address info for display on the written check. I want the disbursement table to reflect the ACTUAL address to which the check was sent, even if, many years later, the client's address later changes. Essentially, the purpose of duplicating various fields is for historical purposes.
Hence, my desire to duplicate fields. Not a big deal to recreate each field, but, then again, it should'nt be a big deal to be able to copy or duplicate fields from one table to another.
When you have an issue such as needed to retain an address which was used at the time of a shipment (for instance) then yes, you will insert the address details into your Checks Disbursement table to retain this history.
Another option, which I prefer, is to keep old addresses. When an address changes, create a new address. The 'last address' for each Client is then the default or you can store the AddressID in a Client's field called PreferredAddress. You still would only insert the AddressID into your Checks Disbursement table. The full address thus only exists once but you retain the ability of tracking changes of address.
You can also include an AsOf date field in Addresses. This comes in handy when people live in Florida during winter but in Wisconsin during summer.
Thanks. I see how the other options you suggested can work.
I guess there isn't a way to copy fields from one table to another.
Sorry, I missed that part of your question.
I honestly don't know if FM Pro can copy fields. I have never even opened a copy of Pro (I have always used Developer aka Advanced). In Advanced, you sure can; I do it every day. It truly is worth the investment. I could not imagine developing without the Data Viewer or Debug. Even the Developer Utilities (ability to rename files and all associated files) which keeps import mappings from breaking, is invaluable.
I Agree with LaRetta, using regular FileMaker to develop a database after you get used to the many added advantages to advanced will feel like rowing a boat with only one oar.
Since Table Occurrence is a key term here and VestedInvestor, sounds like someone who is very new to FileMaker, you might want to play with this tutorial to become more familiar with table occurrences and how they control the look and function of FileMaker systems: