How to have second portal open dependent on action in first portal

[SwissMac]

I have a list of clients. Every time I see them I have to record data about them that changes with time and I have to keep all the data collected, one set per date visited. Each set of date dependent data has multiple sub-sections. Something like this:

CLIENT --< DatedFactfind --< Subsection.

The Layout I want to create has the CLIENT name, then a portal showing the list of FactFinds with the dates they were done, and then I want to be able to click a button alongside each dated Factfind to show the relevant details for each Factfind - eg FactfindAssets with sections for Cash, Shares, Funds etc. Each subsection has different fields to suit their asset type.

How do I organise this please? 

[comment]

You can make the button in the portal to DatedFactfind table set a global field to the value of DatedFactfind_ID. Then use this field as the match field to another occurrence of the Subsection table. A portal to this occurrence will show only Subsection records that belong to the clicked DatedFactfind record.

I am afraid I did not understand the part about each subsection having different fields.

 

[SwissMac]

17 minutes ago, comment said:

You can make the button in the portal to DatedFactfind table set a global field to the value of DatedFactfind_ID. Then use this field as the match field to another occurrence of the Subsection table. A portal to this occurrence will show only Subsection records that belong to the clicked DatedFactfind record.

I am afraid I did not understand the part about each subsection having different fields.

 

Sorry, it's hard to explain. The layout has three parts. At the top, the Client Name. In the Middle a portal with a list of the different Factfinds. And at the bottom some way to display the information from each Factfind. I was using a simple 2 level layout with the Client Name and a Tab Control Object with a single portal in each Tab for each subsection of the Factfind. So, the Cash Tab had a portal that linked to the Cash table, while the Shares Tab had a portal that linked to the Shares table, and the Funds Tab linked to the Funds table. Each of those tables had different fields in, which is why I could not use a single table for all of them. But that only allowed for a single Factfind, and I need to record each one. So, I needed to insert a new table between Client and Cash and between Client and Shares and between Client and Funds. I called that new table Factfind. I just don't know how to link everything together... I like your idea of a Global field and I think I get it, but not confident I can do it.

[comment]

I am afraid I am only more confused now. Please explain how many Factfinds can one client have, and what fields do you have in the Factfind table (fields that are common to each Factfind, independent of the type). Then explain how many subsections can one  Factfind have, and - most importantly - how many subsections of the same type can one Factfind have.

 

[SwissMac]

8 hours ago, comment said:

I am afraid I am only more confused now. Please explain how many Factfinds can one client have, and what fields do you have in the Factfind table (fields that are common to each Factfind, independent of the type). Then explain how many subsections can one  Factfind have, and - most importantly - how many subsections of the same type can one Factfind have.

 

OK. I work in a regulated environment where every meeting with a client must be recorded in a booklet called a Factfind. With annual meetings, that means each client has many Factfinds. Each Factfind must be available unchanged for the purposes of Auditing for at least ten years. Each Factfind has many sections. The individual and unchanging information about the client is held in the Client Info table, things like pk_ClientID, Name, Address, Email etc.

In each Factfind the user must record the current financial situation. This obviously changes in between meetings so you cannot just overwrite an old Factfind, you have to create a new Factfind for each meeting. As I said, each Factfind is a booklet and as such has many sections. I have created a separate table for each logical section. So I have dCash, dFunds at the moment for proof of concept but will increase this eventually to include dShares, dRealEstate, etc. Shares and Funds are similar, but not identical (you may know Funds by the name Mutual Funds).

 

Client Info table, has things like pk_ClientID, Name, Address, Email etc

dFactfind table has only a few fields, pk_FactfindID, fk_ClientID, Date, Type, Reason.

dCash has pk_Cash, dDate, dBankName, dAccType, dBalance, dCurrency, dAccNumber, dValueCHF.

dFunds has pk_Funds, dDate, dFundCompanyName, dFundName, dNumberOfShares, dAssetClass, dValueCHF, dValueDate

 

A single Factfind cannot have more than one subsection of the same type, that would not be logical. That is why each Client has many Factfinds. 

[Steve Martino]

Sounds like from the portal you want to go to the related record to see the detail of that portal row?  Otherwise, it hurts my head to read your post...lol.
Are you looking for something like this:

Customers have Equipment and Equipment gets serviced.  In this case I put Equipment for each customer in a one row portal.  The bottom portal shows the related service records for that one piece of equipment.  When a user changes equipment (the arrows in the one row portal), the bottom portal changes to show those related records.
I will tell you (for me) it was quite complicated to maintain with script triggers, populating and un populating globals, etc., so I eventually opted for something simpler

[chris7of9]

The problem is very similar to what I want to achieve - but I think my issue is easier to explain. I have Clients, who can have many policies and each policy can have more than one claim.

The Client view already has the Client details displayed on the left of the screen, a Policy portal next to it and if a policy number is selected (clicked) the policy details are displayed below - all on one screen.

I want to be able to also now display any claims that may exist to the right of the policy details.

Do I need to have another instance of the policy table with a one-to-many link to the claims table in order to make this work?

Let me know if I should have this as a separate thread.

Edited October 31, 2021 by chris7of9

[comment]

5 minutes ago, chris7of9 said:

Let me know if I should have this as a separate thread.

I think that would be much preferable to "hijacking" this thread.

Edited October 31, 2021 by comment

[SwissMac]

4 hours ago, Steve Martino said:

Sounds like from the portal you want to go to the related record to see the detail of that portal row?  Otherwise, it hurts my head to read your post...lol.
Are you looking for something like this:

Customers have Equipment and Equipment gets serviced.  In this case I put Equipment for each customer in a one row portal.  The bottom portal shows the related service records for that one piece of equipment.  When a user changes equipment (the arrows in the one row portal), the bottom portal changes to show those related records.
I will tell you (for me) it was quite complicated to maintain with script triggers, populating and un populating globals, etc., so I eventually opted for something simpler

Yes, that looks very similar to what I am trying to achieve, except I would have a multiple row portal where you have your red portal. Your button with the arrow on it is in one row of a portal, just as I want mine to be. And everything in the lower, green, portal changes when you click the button, which is again what I want mine to do so that you only see the information relevant to each item of equipment (for you) or each Factfind (for me). Mine is slightly different in that everything in the green area is for the same date, for instance, using your setup, an itemised list of what is done in an individual annual tune up. 

When you click on the button with the arrow on it, what does the script do? And how are the relationships arranged? 

[comment]

8 hours ago, SwissMac said:

A single Factfind cannot have more than one subsection of the same type

In such case I would suggest you use only two tables, Clients and Factfinds, and place all the fields for all the sections in the Factfind table. Splitting the sections to separate tables may seem more convenient in terms of having a shorter list of fields to maintain, but it will clutter everything else.

Then it's a simple matter of setting a global field to the selected Factfind's ID and placing the various fields from the other TO of Factfinds inside their respective tab panels.

Alternatively, you could place a one-row portal inside each tab panel and filter it so that it shows data only from the selected Factfind. Then you wouldn't need the second relationship and could use a variable instead of the global field.

There's just one more thing that needs to be worked out and that is what happens when you move to another client. We can discuss this after you decide which route you want to take.

--
For completion, I should mention briefly another option to organize the data, namely the EAV model - where you would have a table of "questions" and another table for "answers" (think of each Factfind as a survey). But this is not an undertaking I would recommend to a beginner.

 

 

[SwissMac]

1 hour ago, comment said:

In such case I would suggest you use only two tables, Clients and Factfinds, and place all the fields for all the sections in the Factfind table. Splitting the sections to separate tables may seem more convenient in terms of having a shorter list of fields to maintain, but it will clutter everything else.

Then it's a simple matter of setting a global field to the selected Factfind's ID and placing the various fields from the other TO of Factfinds inside their respective tab panels.

I did consider this but wasn't sure about it. If I use only two tables, why do I need any TOs or global fields? I don't understand how this would work...

[comment]

You need a second TO of the Factfinds table in order to have a relationship like this:

Clients::gSelectedFactfindID = Factfinds 2::FactfindID

Fields from the  Factfinds 2 TO, when placed on the layout of Clients. will display data from the selected Factfind record (whose ID is in the global .gSelectedFactfindID field).

As I mentioned earlier you don't need this if you decide to use filtered portals instead. But that requires more layout work and assumes that a client will not have a huge amount of related Factfinds (more than a couple of hundred).

 

Edited November 1, 2021 by comment

[SwissMac]

5 hours ago, comment said:

You need a second TO of the Factfinds table in order to have a relationship like this:

Clients::gSelectedFactfindID = Factfinds 2::FactfindID

Fields from the  Factfinds 2 TO, when placed on the layout of Clients. will display data from the selected Factfind record (whose ID is in the global .gSelectedFactfindID field).

So, using this method I would not need to place the selected records from Factfinds 2 into a portal to display them, I could just lay them out on the non-portal area eg in a tabbed layout, and would only need one duplicate TO of Factfinds (ie Factfinds 2 in addition to Factfinds) no matter how many Tabs I used?

How do I then show the variable number of Bank Accounts in the Cash Tab, some people have only one, some people have five or six or more. In the Funds Tab there is again a variable number of Funds, some people have none, some have one or two, some have 20 or so. The structure needs to be able to account for this variability - that is why I created extra tables in the first place. Hard coding for Bank Account 1, Bank Account 2...n or Fund 1...n in the Factfinds table seems messy?

Edited November 1, 2021 by SwissMac

[comment]

22 minutes ago, SwissMac said:

using this method I would not need to place the selected records from Factfinds 2 into a portal to display them, I could just lay them out on the non-portal area eg in a tabbed layout, and would only need one duplicate TO of Factfinds (ie Factfinds 2 in addition to Factfinds) no matter how many Tabs I used?

Yes.

23 minutes ago, SwissMac said:

How do I then show the variable number of Bank Accounts in the Cash Tab, some people have only one, some people have five or six or more. In the Funds Tab there is again a variable number of Funds, some people have none, some have one or two, some have 20 or so.

You will need a separate table for the bank accounts. And you will need to place two occurrences of this table on the relationships graph - one connected to Factfinds, and the other connected to Factfinds 2. And the portal you will place on this layout will be to the other TO. Likewise for the funds and anything else that one Factfind has many of.

 

[SwissMac]

46 minutes ago, comment said:

Yes.

You will need a separate table for the bank accounts. And you will need to place two occurrences of this table on the relationships graph - one connected to Factfinds, and the other connected to Factfinds 2. And the portal you will place on this layout will be to the other TO. Likewise for the funds and anything else that one Factfind has many of.

 

Can you please specify "other TO"? Factfinds 2 or Cash 2 (the second TO of the table for the Bank accounts), and when you say "this layout" you are referring to the single layout we have been discussing, or a new Layout of some sort entirely on which to display the Bank Accounts, Funds etc?

Edited November 1, 2021 by SwissMac

[comment]

5 hours ago, SwissMac said:

Can you please specify "other TO"?

Let me try and put it this way: first, you have the "core" relationships:

Clients -< FactFinds -< BankAccounts

Now, for the purposes of building the layout you asked for, you will add some auxiliary relationships:

 Clients -< FactFinds 2 -< BankAccounts 2

This layout (the  same and only layout we have been discussing all along, which is a Form view layout showing records from the Clients table) will have a portal to FactFinds (with a button to select a FactFind), fields from FactFinds 2 placed directly onto the layout (these will show data  from the selected FactFind) and a portal to BankAccounts 2 (showing the bank accounts belonging to the selected FactFind).

At this point I would suggest you try and implement this. I believe that will make things clearer.

 

[SwissMac]

2 hours ago, comment said:

Let me try and put it this way: first, you have the "core" relationships:

Clients -< FactFinds -< BankAccounts

Now, for the purposes of building the layout you asked for, you will add some auxiliary relationships:

 Clients -< FactFinds 2 -< BankAccounts 2

This layout (the  same and only layout we have been discussing all along, which is a Form view layout showing records from the Clients table) will have a portal to FactFinds (with a button to select a FactFind), fields from FactFinds 2 placed directly onto the layout (these will show data  from the selected FactFind) and a portal to BankAccounts 2 (showing the bank accounts belonging to the selected FactFind).

At this point I would suggest you try and implement this. I believe that will make things clearer.

 

I've been trying to implement it after every comment but I'm not understanding what I'm doing. I did what you said:

1. Created Form Layout based on <Client Info to Factfind> table. It's an Alias of Client Info, one of 6 that are used for many other functions.
2. Added ClientInfoToFactfind::Client Name
3. Created a 4 row Portal based on dFactfind
4. Added all the fields from dFactfind to Portal ie pk_FactfindID, fk_ClientID, Date, Type, Reason.
5. Added Scripted Button to set global field to Factfind::_PK_Factfind_ID using script in 6:
6. Set Field [ Client Info to Factfind::gFactfindID_dCash ; dFactfind::_PKFactfind_ID ]
7. Added Tab Object with 2 Tabs - Cash and Funds
8. In Cash Tab I added Portal to Table <dCash 2> and added all the 7 fields in dCash 2.

Points I am confused by.

• You said to use 2 Tables, but now there are 4 plus Aliases.
• You said to create "core relationships Clients -< FactFinds -< BankAccounts but these appear to be unused on the layout.
• You said to add data from Factfind directly onto the layout, but the data from dFactfind is already in the Portal in 3. (above) while the data from dCash is supposed to appear in the Tab named Cash and doesn't.

I'm completely confused.

 

[comment]

15 hours ago, comment said:

Clients::gSelectedFactfindID = Factfinds 2::FactfindID

This is the first thing that jumps out of your screenshot.
 

I am attaching a bare-bones demo that you can use for learning purposes. Note that it's not perfect: if you switch to another parent, the previous selection remains. This is on purpose to keep the demo as simple as it can be.

 

ViewSelected.fmp12

[SwissMac]

14 minutes ago, comment said:

This is the first thing that jumps out of your screenshot.
 

I am attaching a bare-bones demo that you can use for learning purposes. Note that it's not perfect: if you switch to another parent, the previous selection remains. This is on purpose to keep the demo as simple as it can be.

 

ViewSelected.fmp12 172 kB · 2 downloads

Thank you very much for doing that. I will look at it tomorrow now because I am absolutely exhausted and I have too many loose ends to think about with the database so will try again tomorrow.

[SwissMac]

On 11/1/2021 at 11:29 PM, comment said:

This is the first thing that jumps out of your screenshot.

What was wrong ith it?I tried to adapt your example to my situation but there were many things I could not do and I still don't understand how to add a second portal or a third - do I create a new set of two extra TOs for each extra portal?

[comment]

5 hours ago, SwissMac said:

What was wrong ith it?

What was wrong is that you did not have it. Instead you had two 2 TOs of FactFind connected to Clients, both matching on ClientID. Such duplication achieves nothing.

 

5 hours ago, SwissMac said:

I still don't understand how to add a second portal or a third - do I create a new set of two extra TOs for each extra portal?

If you mean a second portal or a third to view a second or a third grandchild table, then no; you just connect a 2nd occurrence of each table to the Child 2 TO, same as the first grandchild.

 

 

[SwissMac]

8 hours ago, comment said:

What was wrong is that you did not have it. Instead you had two 2 TOs of FactFind connected to Clients, both matching on ClientID. Such duplication achieves nothing.

 

If you mean a second portal or a third to view a second or a third grandchild table, then no; you just connect a 2nd occurrence of each table to the Child 2 TO, same as the first grandchild.

 

 

Am I right that the rule here is that when adding a Portal to show a Grandchild Table on a Layout based on the Parent Table that has a relationship with a Child Table, I must match the Grandchild with a TO of the Child, and that any other Grandchild must also link with this second TO of the Child Table?

So, in this way, the Parent table would show the Client name for example, then the first portal would show the Child table info, and if I wanted to show any of the details from the Child info table which is held in Grandchild tables these should only link to a copy TO of the Child Table whose data comes from the original TO of the Child Table, and is shown in the first portal?

[comment]

2 hours ago, SwissMac said:

Am I right that the rule here is that when adding a Portal to show a Grandchild Table on a Layout based on the Parent Table that has a relationship with a Child Table, I must match the Grandchild with a TO of the Child, and that any other Grandchild must also link with this second TO of the Child Table?

No, there is no such rule. The only rule is that the relationship needs to be defined in such way that the related set is what you want it to be. For example, in the given situation where the parent table has a global field holding the selected child's ID, you could connect the grandchild table directly to the parent, using the grandchild's foreign key to the child table as the match field - see the attached demo.

I am afraid I did not understand the rest.

 

ViewSelected2.fmp12

Edited November 13, 2021 by comment

[SwissMac]

1 hour ago, comment said:

No, there is no such rule. The only rule is that the relationship needs to be defined in such way that the related set is what you want it to be. For example, in the given situation where the parent table has a global field holding the selected child's ID, you could connect the grandchild table directly to the parent, using the grandchild's foreign key to the child table as the match field - see the attached demo.

I am afraid I did not understand the rest.

 

ViewSelected2.fmp12 172 kB · 0 downloads

This is the place you lost me last time - I cannot see how to add another portal to display data from a different grandchild. Eg boy grandchild and girl grandchild. Whatever I do to copy what you have done does not work. Yes, I can add one portal to a layout with one existing portal, but I cannot add another. Perhaps I need a button inside the grandchild portal to show a Great Grandchild in a different layout eg for recording different values for the record in a Grandchild recorded over time eg Value in 2019, value in 2020, value in 2021.

Which approach would you recommend?

[comment]

30 minutes ago, SwissMac said:

I cannot see how to add another portal to display data from a different grandchild.

Like this (attached).

ViewSelected3.fmp12

[SwissMac]

4 minutes ago, comment said:

Like this (attached).

ViewSelected3.fmp12 188 kB · 1 download

Thanks, that makes it much clearer.

How does one then add a 4th generation eg a Great-Grandchild? Just to see the logic progress one more step... In your example the foodstuffs will not change over time, but maybe the recipe would and to keep a record of both the old and new recipe how would that work? For me I'm dealing more with numbers that need to be recorded over time.

 

[comment]

3 minutes ago, SwissMac said:

How does one then add a 4th generation eg a Great-Grandchild?

It depends on how you want this to work. If you want to continue the same principle, then you would first need to select a grandchild and place its ID in a global field. Then use this to include only the great-grandchildren that are children of the selected grandchild in the related set.

Please note that I am discussing only methods to display selected data. Your last paragraph raises questions regarding how the data should be organized in the first place. I am not at all convinced that the example of changing recipes reflects your actual need. You might want to start a new thread regarding your data structure. I am certainly not going to express any opinion based on such sketchy description as "numbers that need to be recorded over time".

 

[SwissMac]

22 minutes ago, comment said:

It depends on how you want this to work. If you want to continue the same principle, then you would first need to select a grandchild and place its ID in a global field. Then use this to include only the great-grandchildren that are children of the selected grandchild in the related set.

Please note that I am discussing only methods to display selected data. Your last paragraph raises questions regarding how the data should be organized in the first place. I am not at all convinced that the example of changing recipes reflects your actual need. You might want to start a new thread regarding your data structure. I am certainly not going to express any opinion based on such sketchy description as "numbers that need to be recorded over time".

 

Well, I tried to write it in a full way, but you said you didn't understand so I wrote it in as simple a way as possible and you say that's not enough. I'm not an expert at Filemaker, I have just one database which gets looked at about once every 3 or 4 years but I'm happy to change how I say things if you could suggest a way that clarifies how you would like me to write it down. I will then open a new thread on data structure as you kindly suggest. What information is needed, and how should I describe it?

[comment]

41 minutes ago, SwissMac said:

What information is needed, and how should I describe it?

That's a good question. I am not sure I have a good answer. Perhaps start by describing the real-world entities you want to keep track of, and how they are related. Especially important is the cardinality: how many of Y's can one X have and vice versa.

One more note about the current topic: earlier you said:

2 hours ago, SwissMac said:

Perhaps I need a button inside the grandchild portal to show a Great Grandchild in a different layout

Your question here was about displaying a reduced set in portal on a layout of the parent table (at least that's how I understood it). Displaying the same reduced set in a new window (or, if you prefer, in the same window) using a layout of the target table is another option - and it is much simpler to implement than what we were discussing here. All you need for this is the Go to Related Record [] script step. And you can keep drilling down in the hierarchy - e.g open a window showing the selected child's grandchildren, then open another showing the selected grandchild's great-grandchildren. All this can be done using the existing core relationships, with no need for additional TOs.

 

Edited November 13, 2021 by comment

[SwissMac]

1 hour ago, comment said:

That's a good question. I am not sure I have a good answer. Perhaps start by describing the real-world entities you want to keep track of, and how they are related. Especially important is the cardinality: how many of Y's can one X have and vice versa.

You mean like One to Many etc? Or how many the many would be?

[SwissMac]

2 hours ago, comment said:

Your question here was about displaying a reduced set in portal on a layout of the parent table (at least that's how I understood it).

Not a reduced set, a cascading One to Many pattern, as described in my original question. The method that keeps on opening a new layout to show the next level of detail is OK for data entry (well, if I get it to work), but I'm having problems visualising how to display the information in an overview that can be printed. Perhaps it's obvious but I can't see it.

Cardinality (not sure if this is helpful for what you are looking for):

Let's assume one client can have 20 factfinds.

Each factfind can have a dozen bank accounts (although the record I've found was 38 bank accounts for one person!) plus each Factfind can have up to 50 Shares plus each Factfind can have up to 30 mutual funds and each Factfind can have up to a dozen houses (usually only one though.

Each bank account has a balance that varies over time is different every year but I need to be able to show what the balance was at any time in the last ten years when advice was given.

Each Share (Stock) also has a value that varies over time and must be recorded on dates when advice is given, and kept for ten years.

Each Mutual Fund has a value that varies daily and must be recorded on dates when advice is given, and kept for ten years.

Each house has a value that varies not so much, but does vary and must be recorded on dates when advice is given, and kept for ten years.

Should I move this into a new question? 

Edited November 14, 2021 by SwissMac

[comment]

5 hours ago, SwissMac said:

Not a reduced set, a cascading One to Many pattern, as described in my original question.

Well, if you want to see only some grandchildren of a parent, I would call that a reduced set.

 

5 hours ago, SwissMac said:

I'm having problems visualising how to display the information in an overview that can be printed.

Uh-oh. You haven't said anything about printing. You asked about portals - and portals are meant for displaying data on screen, not for printing. If you intend to produce a printout that lists all grandchildren of a parent from one table, and then lists all grandchildren of the same parent from another table, then you're looking at a considerably difficult task. And just about everything suggested in this thread is irrelevant to this task.

 

[SwissMac]

7 hours ago, comment said:

Well, if you want to see only some grandchildren of a parent, I would call that a reduced set.

 

Uh-oh. You haven't said anything about printing. You asked about portals - and portals are meant for displaying data on screen, not for printing. If you intend to produce a printout that lists all grandchildren of a parent from one table, and then lists all grandchildren of the same parent from another table, then you're looking at a considerably difficult task. And just about everything suggested in this thread is irrelevant to this task.

 

I have moved the data structure issue to a different section, but I need to be able to one way or another see everything, but not necessarily on the same page.

Printing is just one use for the data. Most importantly though I need to be able to see it. I have created some single record layouts for data entry for each table, but getting an overview after the data entry has been done is where I thought a portal would be useful. If there is a better way I am all for learning it. Like I said, I'm really not an expert and appreciate all the help I can get.

[LaRetta]

On 11/14/2021 at 6:07 AM, SwissMac said:

Like I said, I'm really not an expert and appreciate all the help I can get.

A sound base structure is the most important aspect of any design and, although forum threads are great for simpler questions they can get bogged down in complex solutions such as yours, as you are discovering.  Comment, or another top Developer can save you hundreds of hours and high stress now, as well as saving you from refactoring a poor design later.  DAMHIK!

And no, I'm not pitching ... just giving my honest evaluation and I'm not available anyway.  You are quite intelligent and, once a good base has been built, the stress will disappear and you'll enjoy taking your solution the rest of the way, using forums where you get stuck!  Regardless of your decision, we will try to help as we can and I wish you the best with your project. 🙂

Added: To clarify, I'm suggesting you hire a Developer to establish your base structure.  It'll end up costing you a lot less that way.

Edited November 16, 2021 by LaRetta

[SwissMac]

8 hours ago, LaRetta said:

A sound base structure is the most important aspect of any design and, although forum threads are great for simpler questions they can get bogged down in complex solutions such as yours, as you are discovering.  Comment, or another top Developer can save you hundreds of hours and high stress now, as well as saving you from refactoring a poor design later.  DAMHIK!

And no, I'm not pitching ... just giving my honest evaluation and I'm not available anyway.  You are quite intelligent and, once a good base has been built, the stress will disappear and you'll enjoy taking your solution the rest of the way, using forums where you get stuck!  Regardless of your decision, we will try to help as we can and I wish you the best with your project. 🙂

Added: To clarify, I'm suggesting you hire a Developer to establish your base structure.  It'll end up costing you a lot less that way.

Thank you for your comment LaRetta. A lot of what you say is true, and I don't disagree that engaging a developer to design your complete project can be helpful in some (most?) cases. It isn't always affordable, nor is it a panacea though. Developers can race along with their own ideas, or try and squeeze you into one of their own "ready made" solutions that take more time to adapt than it takes to write a new one, and the result can be overkill for what might be a simple need. Also, there are not always many developers available. 

My goal is different though, I want to understand the logic and methods of Filemaker. I have been on a couple of courses, but they went too slowly to begin then as the trainer realised time was short became far too fast for me (I'm over 60 and not as spry as I used to be). The Filemaker Pro Help on the internet is definitely improved compared to what was available with FMP 10 which is what I started with (I am now on 17.) 

Comment has been excellent in how he has been patient and helped me to understand the principles better. I'm never going to be a developer, but I hate not understanding how things work, and I do genuinely enjoy working on a project, so long as I can call on help when I get stuck. In this case the data design was where I was going wrong conceptually, and I just needed a gentle nudge to get that through my head. I was too close to the paper-based workflow I have used for 30 years and couldn't see the logic problem, I just knew there was one. Now I have to implement that concept, and there will be learning points to come - indeed, I have asked about a couple of clarifications on the other thread already.

So, thank you for your input and your heartfelt support for paid developers who I do respect. In shorter supply though are good Teachers, and Comment is one of the best I have found.